DataNucleus Forum - View Thread - Improved and simpler JCA integration

Welcome Guest | Register | Login

DataNucleus Forum

Category: Development of DataNucleus

Forum: General Development

Thread: Improved and simpler JCA integration

Quick Go »

No member browsing this thread

Thread Status: Active
Total posts in this thread: 1

[ ]

Author

This topic has been viewed 1330 times and has 0 replies

jfrantzius
Advanced Member

Germany
Joined: Jun 18, 2004
Post Count: 407
Status: Offline


0 Improved and simpler JCA integration

It seems that there is no need for a complete JCA resource adapter implementation. The JDO spec says in chapter "4.3 Scenario: Enterprise Calendar Manager":

In this scenario, the JDO implementation is provided by a vendor that maps Java objects
to relational databases. The implementation uses a JCA Resource Adapter to connect to the
datastore.
The JDO PersistenceManager is a caching manager, as defined by the Connector architecture,
and it is configured to use a JCA Resource Adapter.

"Appendix C Caching Manager" of the JCA 1.5 spec describes a very simple contract between the application server and Caching Managers, by simply using javax.transaction.Synchronization callbacks. Compared to what the current implementation does, it seems all pretty straight-forward:

acquire datastore connections through JCA datasources
register as javax.transaction.Synchronization with the UserTransaction (in PersistenceManager constructor?)
flush upon beforeCompletion()
rollback caches in afterCompletion() if tx had failed
optionally delegate user-initiated JDO transaction demarcation to UserTransaction

There would be no need for

maintaining delegation in jpox.resource.*,
maintaininig lots of code for resource adapter contracts (with only little additional code for the new approach),
no need for .rar provisioning
no need for configuration as a JCA connection factory

IMHO everything would be much more simple, cleaner and easier to maintain compared to maintaining a complete JCA Resource Adapter that is not needed in the first place, as it seems. Apart from that, as much as I can tell, it would also simply work better as requests wouldn't be funneled through one and the same ManagedConnectionImpl.

From a user's point of view, code would be easier "portable" between container and non-container environments, as the PersistenceManagerFactory could be obtained as usual (no need for JNDI lookups). The difference would only be found in the jdo.properties file, where ConnectionFactoryName properties would have be used.

---------------------------------------
This post has been recovered after a database corruption and might completely or partially lack replies. This thread had 2 replies before corruption.

[Apr 19, 2006 9:49:04 PM]

[Link]

[ ]

Current timezone is GMT
Sep 10, 2010 5:29:34 PM