Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Moved auto-commit logic from Jaybird to the Firebird. #1
Jaybird shows horrible performance in auto-commit mode while executing
Solution: Firebird API has its own auto-commit flag. Firebird knows for
Main changes in code are:
Jaybird shows horrible performance in auto-commit mode while executing lots of small queries. Reasons: 1. Every time a statement is being executed a new transaction starts and commits. 2. Even if there were no changes at all (e.g., simple select statement) Jaybird starts and commits transaction. Solution: Firebird API has its own auto-commit flag. Firebird knows for sure if anything did actually change, so Jaybird might rely on it. As a result: 1. It saves start and commit calls; 2. It executes commits only if something really changed; 3. Internally it works faster even if changes appeared because it doesn't restart a transaction. Practical results: it allowed me to make OpenCMS work 3-5 times faster with Firebird. I suppose it's not the only case, because some systems (especially the ones using ORMs) tend to execute lots of small selects. Main changes in code are: 1. Removed AutocommitTransactionCoordinator. LocalTransactionCoordinator with enabled autoCommit flag does exactly what we need. 2. When we change autoCoommit to true/false - we commit previous transaction manually, so that it restarts with new TPB.
The reason is that JPA Firebird driver was very slow due to lots of select statements per page view being followed by rollbacks (even if it changed nothing). Non-JPA implementation + auto-commit-friendly Jaybird driver (implemented here FirebirdSQL/jaybird#1) made page views 3-5 times faster with Firebird.
I will start experimenting with this next week. As I commented on the firebird-devel mailinglist, I expect some caveats both in the behavior of Firebird with
On Sun, Jun 7, 2015 at 7:26 PM, Mark Rotteveel email@example.com
I implemented this as part of http://tracker.firebirdsql.org/browse/JDBC-399 (both in Branch_2_2 and master). I did not use your pull request directly (although I did reference it to see what you changed). Thanks for the suggestion and the ground work!
This option is enabled by specifying the connection property
With this option, Jaybird will configure the transaction to use
On statement completion (as specified in JDBC), result sets will still close unless they are holdable over commit. The result set is only closed clientside, which means that the cursor remains open server side to prevent roundtrips. This may lead to additional resource usage server side unless explicitly closed in the code. Note that any open blobs will be closed client and serverside (until this is improved with JDBC-401).
A connection can be interrogated using
If you manually add
Support for this option is experimental, and should only be enabled if you 1) know what you're doing, and 2) if you really need this feature. Internally
Whether or not this improves performance has yet to be tested. The Jaybird testsuite does not show a noticeable difference either way, but most tests only use a a few statements on a single connection.
I will release a snapshot somewhere in the next week, or you can compile it yourself.