Subject | Re: PreparedStatement caching and Connection Pools |
---|---|
Author | Roman Rokytskyy |
Post date | 2003-04-28T20:38:38Z |
Hi,
that it checks database metadata if driver supports prepared
statements across commit and either clean statement pool in
Connection.commit() or keep it.
during commit/rollback, but I might have overlooked something.
Actually Firebird supports open statements across commits, but nobody
really fully tested this feature, so FBDatabaseMetaData
reports "false". So you can try using same prepared statement in
different transactions, should work.
I the future (most likely before May 20th, and for sure before end of
May) I plan to add a connection pool with prepared statement cache,
so you will not need to bother yourself about such things.
Best regards,
Roman
> Is there a way to share a prepared statement across connections? II have exactly same scheme in my JDBC pool. The only difference is
> guess my problem is that I use a connection pool. Currently, my
> transaction object encapsulates a connection and a hashmap of
> prepared statements.
> Before preparing a new statement, I see if it has already been
> created in "this" transaction. The problem is that I get
> preparation benefits only when I repeat many of the same actions in
> a single transaction.
that it checks database metadata if driver supports prepared
statements across commit and either clean statement pool in
Connection.commit() or keep it.
> The only alternative I could think of is preparing all myI checked the code and I see no place where statement is released
> statements in all my pooled connections so that each has a prepared
> statement library. However, this seems overkill. Does JayBird have
> some functionality that might help me here or are there standard
> patterns for solving this kind of problem?
during commit/rollback, but I might have overlooked something.
Actually Firebird supports open statements across commits, but nobody
really fully tested this feature, so FBDatabaseMetaData
reports "false". So you can try using same prepared statement in
different transactions, should work.
I the future (most likely before May 20th, and for sure before end of
May) I plan to add a connection pool with prepared statement cache,
so you will not need to bother yourself about such things.
Best regards,
Roman