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.

You might want to look at activeMQ. It works as I described, putting
the leftover messages into long term storage, usually a relational
database. I'd be very interested to know how well it works using
firebird as the long term storage.

If your requirements don't fit jms very well, I'd be quite interested
to know how your system performs.

thanks
david jencks

On Aug 1, 2005, at 5:19 AM, johnson_dave2003 wrote:

> My apologies for cross-poting this inquiry.  I originally posted this
> on Firebird-support a couple of days ago, but received no response.
> Since I am using the Jaybird drivers, I thought my next stop should be
> here.
>
> Thanks in advance.
>
> I am prototyping a queueing system built around Firebird, similar in
> core functionality to MQ series from IBM.  My first series of
> functional test cases may have exposed a bug, or possibly a side
> effect of an optimization, in either the Firebird engine or (less
> likely) the jaybird JDBC driver.  I have not confirmed yet that it
> happens in Super server, and I am fresh out of Windows installations
> to test against.  Installation is Firebird 1.5.2 Classic running under
> Fedora 3 linux and sun JVM 1.5.0 build 3.
>
> The functional requirement being tested is that the system
> administrator  must be able to construct and destroy queues and their
> backing storage (1 table + 1 generator) dynamically at runtime.
>
> Architecturally, the queue system "owns" its own firebird database
> instance, and connects to it using a connection pool of configurable
> size.
>
> Queue users (including the administrator) connect to the queue system
> via a sockets connection, and the queue system ties requests from the
> connections to database connections in real time for the duration of
> the operation.  On commit, the firebird connection is released back to
> the connection pool.
>
> When a queue is constructed, the backing table and sequence generator
> are constructed, and all 4 of the queries that address the backing
> table and the 1 query that addresses the generator are prepared in all
> connections.
>
> When a queue is destroyed, the queries that addressed the backing
> table and sequence generator are closed and (allegedly) disposed of,
> and  then the table and generator themselves are dropped.
>
> The test case is simple.
>
> 1. Construct a connection pool of 2 connections
>
> 2. construct and destroy the same queue repeatedly - pseudocode
> follows:
>
>     for (int count=0;count<10;count++ {
>         executeConstructDDL ();
>         for each conection executePrepareDml();
>         commit ();
>
>         for each connection executeCloseDml();
>         executeDropDDL ();
>         commit;
>     }
>
>
>
> On the second pass, the attempt to prepare the first query against the
> second connection will fail with this message:
>
> org.firebirdsql.jdbc.FBSQLException: GDS Exception. 335544343. invalid
> request BLR at offset 64
> table id 198 is not defined
> <snip ... call stack >
>
> Is this (a) a known constraint of FB (deliberate optimization), (b) a
> new bug that needs to be reported, (c) an old bug that is resolved in
> FB2, or (d) something that is a function of the jaybird JDBC connector
> (which I would then need to report to the firebird-java list)?
>
>
>
>
>
>
>
> YAHOO! GROUPS LINKS
>
> ▪  Visit your group "Firebird-Java" on the web.
>  
> ▪  To unsubscribe from this group, send an email to:
>  Firebird-Java-unsubscribe@yahoogroups.com
>  
> ▪  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service.
>
>