Details
Bug
Closed
Major
Description
There are various issues with the transaction and connection handling in the new jdbc datastore.
See the old JDBC data stores for proper transaction handling and related connection handling.
There are various issues with the transaction and connection handling in the new jdbc datastore.
See the old JDBC data stores for proper transaction handling and related connection handling.
To introduce the problem let's start with a code snippet:
Transaction t = new Transaction();
FeatureStore s1 = (FeatureStore) dataStore.getFeatureSource("type1");
FeatureStore s2 = (FeatureStore) dataStore.getFeatureSource("type2");
s1.setTransaction(s1);
s2.setTransaction(s2);
// write something with s1
// write something with s2
t.commit();
t.close();
Am I right in assuming that if anything goes wrong with the commit
of the statements performed against s1, also the ones in s2 should
fail? That seems like basic transaction atomicity guarantee to me.
And it should be respected provided the two stores are using the
same connection to the database.
However, as far as I can see, the current design of the JDBCDataStore
will attach two separate JDBCState to the transaction, each own
containing a different connection. Meaning we are playing with
one GeoTools transaction, but two JDBC connections, thus two
separate database transactions.
To fix this we have to ensure for each (Transaction,JDBCDataStore)
pair there is one and only one database connection.
I implemented a patch for that, which was actually real easy to do
since connection grabbing was nicely centralized and
everything was already in place, even the state object
(JDCBTransactionState) necessary to handle the connection
independently from the the various feature sources... which
makes me really think this idea was already in the cards, but for
some reason the implementation was not finished.
I'm going to attach a patch that finishes the job and ensures proper transaction atomicity respect