> I realize I am butting my head in here where it may not be wanted and
> it is possible that firebird does not behave like other relational
> databases but....
>
> The access patterns needed for most queueing systems are rather
> different from what most relational databases are good at. Usually
> queueing systems can keep more or less up with demand, and keep all the
> messages in memory. In this case a rolling log based persistence
> scheme works really well: in the "send" transaction you write the
> incoming message to the log (as well as keeping it in memory) and in
> the "receive" transaction you write a token indicating that the message
> has been delivered. Some other thread that cleans up the log
> correlates the 2 log entries and discards both. This thread only has
> to actually process messages that haven't been delivered, usually a
> very small fraction of the total.

I agree with you here :). I would think that Firebird will perform even
worser than other (pessimistic) engines. If the pattern above is
implemented, the main outcome most likely would be a permanent garbage
collection of the deleted messages and what is left will be used for message
delivery.

So, the only "advantage" of using Firebird I see is its XA-ness which allows
to create transactional queries without much programming. Maybe it's worth
it?

Roman