Subject Re: [Firebird-Java] Transaction parameters + Jaybird
Author Roman Rokytskyy
25.01.2011 23:33, Alec Swan написав(ла):
>> Connection connection =
> DriverManager.getConnection("jdbc:firebirdsql:localhost/3050:c:/example.fdb?"+
> "TRANSACTION_READ_COMMITTED=isc_tpb_read_committed,"+"isc_rec_version,isc_tpb_read,isc_tpb_nowait",
> "SYSDBA", "masterkey");
> Does Jaybird support java.sql.Connection#setTransactionIsolation(int level)
> standard JDBC call? In other words, will the following code result in
> transaction isolation level to be set to REPEATABLE_READ on the Jaybird
> connection?

Yes. In fact, what you specify in the connection parameters is an
override for the built-in mapping between JDBC isolation levels and TPB
constants of Firebird. So, whenever the application calls


the specified mapping will be used. You can also specify mappings for
other isolation levels as well.

> ComboPooledDataSource comboPooledDataSource = new ComboPooledDataSource();
> comboPooledDataSource.setJdbcUrl("jdbc:firebirdsql:embedded:c:/example.fdb?lc_ctype=UTF8");
> comboPooledDataSource.setUser(FirebirdDatabaseManager.FIREBIRD_USER_NAME);
> comboPooledDataSource.setPassword(FirebirdDatabaseManager.FIREBIRD_PASSWORD);
> comboPooledDataSource.setPreferredTestQuery("select current_timestamp from
> rdb$database");
> Connection connection = comboPooledDataSource .getConnection();
> connection.setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_READ);

The default mapping of Jaybird is specified in file, the REPEATABLE READ is mapped to

> A side question is if there is any benefit of using FBWrappingDataSource
> over c3p0 ComboPooledDataSource?

The only advantage that I can think of, is that it exposes the Firebird
specific properties via setters and getters, that makes the
configuration somewhat more readable. Also it has so called "connection
tracking", which simplifies debugging of the faulty applications. The
pool logs the places where connection was allocated and where it was
closed, and if there is an attempt to close it for a second time, it
will print the appropriate stack traces.

But that's it.

Our pool was written when the c3p0 and dbcp pools were in pretty initial
state. Time passed, they have advanced their code bases, so there is no
really good reasons not to use them now.