On Fri, Sep 23, 2011 at 2:18 PM, Matheus Degiovani
<matheus@...>wrote:

>
> The firebird manual says that generators are thread-safe [1]. How does the
> firebird engine guarantee that two consecutive executions of a "SELECT
> NEXT VALUE FOR..." do not return the same value?

Generator values are stored on generator pages. In shared cache
architectures (i.e. SuperServer) a connection that changes a generator value
gets a transient write lock on the page, makes its change and releases the
page. In a cache-per-connection architecture (e.g. super-classic, classic)
a connection that changes a generator value reads the appropriate generator
page, gets a transient write lock on the page, and makes its change. If
another connection wants to read or change a generator value on that page,
it requests a read lock on the page which causes the connection that holds
the write lock to write the page and release its lock. The other connection
reads the page from disk.

In fact, the write is real, but the read will be satisfied from the
operating system page cache.

> Does it use a lock on the RDB$GENERATOR table?

No.

> Does the call to "SELECT NEXT VALUE..." block, when
> another thread is reading/writing into it?

Not exactly. See above.

> Would that mean that having
> multiple clients connected and issuing these commands simultaneously
> degrade the performance of the database?
>

Yes, under classic, but not particularly SuperServer. This is true for any
high contention page (e.g. header page, transaction inventory page, page
inventory pages).

>
> My application case is the following: I want to append a column to some
> tables in my database representing an "update counter". Whenever an insert
> or update command is issued, this field will be incremented (globally for
> the whole database).
>

Should work OK ... better or worse depending on the architecture.

Good luck,

Ann


[Non-text portions of this message have been removed]