|
|
|
 |
|
Sort Order:
[
Permalink
| « Hide
]
Erik Bengtson added a comment - 25/Jan/07 06:54 AM
needs to delegate to StoreManager since DB4O has specific transaction handler
When considering this, also there is
Adding comment from Kenney Westerhof originally raised as a separate issue but then how can it be an issue if it doesnt appear in released code
When configuring a PersistenceManagerFactoryImpl.JDO_CONNECTION_FACTORY_PROPERTY with a DataSource, I get a ClassCastException in ConnectionFactoryImpl: [Ljava/lang/Object; This is because of: {noformat} if( omfContext.getStoreManager() != null ) { ! conn = ((RDBMSAdapter)omfContext.getStoreManager().getDatastoreAdapter()).getConnection(new ConnectionProviderPriorityList(), (DataSource[])dsTx, isolation); } {noformat} the dsTx is initialized as new Object[1] in the constructor: {noformat} if (config.getConnectionFactory() != null) { if (!(config.getConnectionFactory() instanceof DataSource) && !(config.getConnectionFactory() instanceof XADataSource)) { throw new UnsupportedConnectionFactoryException(config.getConnectionFactory()); } ! dsTx = new Object[1]; dsTx[0] = config.getConnectionFactory(); } {noformat} even though config.getConnectionFactory returns a DataSource. Why is ConnectionManager a separate class? Should be AbstractConnectionFactoryImpl and then we dont need ConnectionManager. ConnectionManager is called by one class (ConnectionFactory) and calls one class (ConnectionFactory) and has very little functionality (a pool) so should be part of a base ConnectionFactoryImpl IMHO. Any reasons why not? It is also currently duplicated under org.jpox.resource for no apparent reason
A JCA container has a ConnectionManager, so JPOX does not need to handle the caching of connections.
In standalone mode the ConnectionManager needs to do the pooling to avoid creating multiple connections for the same transaction, and this is the reason of having two implementations. The ConnectionFactory is there only to create connections, and whenever we add another datastore, we have to implement only it and not a new ConnectionManager. - ConnectionManager is bound to container (standalone, JCA) - ConnectionFactory is bound to datastore (rdbms - javax.sql.DataSource, db4o) Our new transaction handling is pretty much a simplified version of a JCA container. RDBMSManager has dsTx, dsNontx yet ConnectionManager has these too. So we have duplicated data sources (duplicated code block too). What is supposed to be happening here ? Are these RDBMSManager sources going to disappear ? if so, when ? This is a priority since it is stopping any 1.2.0-beta-2 release.
Want to see what is the plan for LocalTransaction, JTATransaction. LocalTransaction should disappear, but what about when in J2SE but user has selected JTA as transactionType ? What happens to org.jpox.transaction.TransactionManager? Does it wrap any found (JTA) TransactionManager? or do we have a new org.jpox.transaction.TransactionManager that is for JTA under J2SE? What work is needed for JCA? For beta-2 we dont necessarily need to jave JTATransaction replaced sicne this wasnt publicised in beta-1 anyway, but JCA should work. Timescales for this? DatabaseAdapter.getConnection() should be part of org.jpox.store.rdbms.ConnectionFactoryImpl somewhere since it does nothing more than create Connections. We only need one way of creating JDBC Connections, so that mere mortals like me can understand it.
> RDBMSManager has dsTx, dsNontx yet ConnectionManager has these too.
> So we have duplicated data sources (duplicated code block too). > What is supposed to be happening here ? Are these RDBMSManager sources going to disappear ? They have now been removed. All datasources should be managed by the ConnectionManager ("rdbms/tx", "rdbms/nontx"). > DatabaseAdapter.getConnection() should be part of org.jpox.store.rdbms.ConnectionFactoryImpl
> somewhere since it does nothing more than create Connections. > We only need one way of creating JDBC Connections, so that mere mortals like me can understand it. (rdbms.)ConnectionFactoryImpl now includes the necessary code for this, and the DatabaseAdapter methods getConnection()/closeConnection() are now marked as REMOVE. They are currently called by LocalTransaction/JCATransaction should be considered completed by now.
|
||||||||||||||||||||||||||||||||||||||||||||||||||
Task
Closed
Critical
Decouple Transaction Management from Storage and support for distributed transactions contract (X/Open)