Subject | Re: [Firebird-Architect] Re: Vulcan architecture and lock tables |
---|---|
Author | Jim Starkey |
Post date | 2006-12-17T16:25:27Z |
paulruizendaal wrote:
resource, require more administration, more overhead by the server, and
are unable to detect cross database deadlocks. And I don't see the upside.
But perhaps more to the point, since most access is done in central
server mode, all locking is done in process, so the lock manager isn't
needed at all. Interbase, from the beginning of time, has always taken
out an exclusive top level on the lock. As long as that lock has held,
accounting for low level locks is done, but the actual locks aren't
expressed in the lock table. If another process needs access to the
database, the lower level locks are expressed, and the top level lock
downgraded to shared. In Vulcan, at least, when running in central
server mode, there is no contention and thread contention is managed by
must higher performance synchronization objects.
> Slightly off-topic, but could I get back to per provider and perNot me. I think they're a bad idea. More lock tables consume more
> database lock tables whilst we are on the topic of lock tables?
>
> I remember this was discussed at the end of a SAS session during the
> 2005 Prague conference. My recollection of that discussion was that
> Jim and Ann both thought that per database lock tables were a good
> idea that had been considered in the past.
>
resource, require more administration, more overhead by the server, and
are unable to detect cross database deadlocks. And I don't see the upside.
But perhaps more to the point, since most access is done in central
server mode, all locking is done in process, so the lock manager isn't
needed at all. Interbase, from the beginning of time, has always taken
out an exclusive top level on the lock. As long as that lock has held,
accounting for low level locks is done, but the actual locks aren't
expressed in the lock table. If another process needs access to the
database, the lower level locks are expressed, and the top level lock
downgraded to shared. In Vulcan, at least, when running in central
server mode, there is no contention and thread contention is managed by
must higher performance synchronization objects.