Subject | Re: [Firebird-Java] Possible bug in Firebird 1.5.2 Classic(cross-post) |
---|---|
Author | David Johnson |
Post date | 2005-08-12T23:43:24Z |
On Fri, 2005-08-12 at 22:46 +0200, Roman Rokytskyy wrote:
jdbc:firebirdsql:embedded:<<localDatabasePath>>?
I was under the impression that embedded did not allow concurrent
connections. If so, then the architecture I cobbled (designed is
definitely too strong a word) will not work with embedded. The user
queue connection is tied to the database connection internally to make
the queue transactional.
Running some math ...
The base specs on your box are roughly 4 to 8 times the throughput that
mine has. Without allowing for (unidentified) handicaps, it appears
that ActiveMQ would perform at about 1.5 to 2x what my classes perform
at if they were on the same hardware.
I would say that Firebird has proven itself as a usable back end for
this sort of application.
I'll get the wire protocol sorted out and put together some more
testcases, then I'll let it loose for anyone who is interested.
My ulterior motive is to ultimately convince people that a persistent
queueing model embedded as a service in the Firebird engine would be
useful and desirable, once Firebird's architecture has proven itself for
the task. I am not out to specifically produce another JMS
implementation, although that might be one stop along the way.
> Try JayBird with embedded engine - you will know more or less the rawIs the url for using embedded
> performance you can get. Usually it is twice as fast as accessing
> database
> over the wire.
>
jdbc:firebirdsql:embedded:<<localDatabasePath>>?
I was under the impression that embedded did not allow concurrent
connections. If so, then the architecture I cobbled (designed is
definitely too strong a word) will not work with embedded. The user
queue connection is tied to the database connection internally to make
the queue transactional.
Running some math ...
The base specs on your box are roughly 4 to 8 times the throughput that
mine has. Without allowing for (unidentified) handicaps, it appears
that ActiveMQ would perform at about 1.5 to 2x what my classes perform
at if they were on the same hardware.
I would say that Firebird has proven itself as a usable back end for
this sort of application.
I'll get the wire protocol sorted out and put together some more
testcases, then I'll let it loose for anyone who is interested.
My ulterior motive is to ultimately convince people that a persistent
queueing model embedded as a service in the Firebird engine would be
useful and desirable, once Firebird's architecture has proven itself for
the task. I am not out to specifically produce another JMS
implementation, although that might be one stop along the way.