|
|
 |
|
|
|
Hm, it's not very much tested, is it?
Well you have 2 issues here
1. Is there more work to this JIRA than just a JTATransaction ? sine the description goes on and on about being in J2EE environments when the users app can sit quite happily in J2SE, and use JNDI. I personally like JIRAs that are concise and describe exactly what is needed so they dont suffer from "feature creep" and never end ... hence why I ask the question "is it complete" 2. What about testing ? As you know very well we dont have testing for J2EE, nor J2SE with JNDI server. As far as I'm concerned testing of such environments should be a separate JIRA, to be worked on by those people who work in it. I hadn't imagined people would lump together parts of a J2EE server instead of taking a complete appserver, that's why it is talking about J2EE. So the requirements rather are JNDI and JTA, with only Weblogic and JBOSS being supported, as it is not specified anywhere how the JTA can be looked up in the JNDI tree.
From my point of view the issue is complete. I won't have time to do testing until January though. Title updated to better match the requirements.
Tagged against 1.2.0-beta-2 since that is in the January timescales. Will be included in 1.2.0-beta-1 but wont be in the docs. Docs will need updating before 1.2.0-beta-2 Here attached there is the JTA support developed against 1.1.5 release.
I have tested in a J2SE env with shiftone JNDI, JOTM, XAPOOL and HSQLDB. It is not tested (and I am quite sure it will not work) in non -jta controlled transactions. I mean that if you want to use the same PMF for both JTA and non-JTA txn this is not a solution. Anyway, on this topic I have some ideas that I could share where and when you want :) (Maybe now would be too long). Thanks for the patch. Regarding the patch
1. Have adapted out a series of JTA TransactionManager Locators added to CVS HEAD under org.jpox.jta (all of those provided in the patch plus several other common app servers too). These need to be plugged into org.jpox.store.rdbms.JTATransaction rather than the current process. This is not currently applied to CVS "RELEASE_1_1" branch 2. Extending the PMF/PM is not the way forward. JPOX already has a mechanism for selecting JTA transaction, using the JPA (and JDO2.1) "transactionType" PMF prop. This is passed to the StoreManager in question and this creates what it needs. JPOX needs to cater for multiple datastore types and multiple transaction types, so this is why it is as it is. 3. JtaSyncedTransaction.java still needs assessing, preferably by someone who actually runs in this environment. That means you Joerg ;-) Having those other JTA lookups is great. We'll probably need to provide some flag or find out what server we're running in, as failing JNDI lookups can be very costly esp. when they end up in a cluster request because they couldn't be resolved locally.
Just as a warning, JtaSyncedTransaction currently is not reusable by different threads, i.e. pooling of PMs is severely hampered at the moment. I'm just fixing this in our local "branch", and will merge when I find the time... All JTA transaction manager locators are now a JPOX plugin (see
All my changes are complete. You now have JBoss, JOnAS, JOTM, OC4J, Orion, Resin, Sun ONE, WebLogic and WebsFear. Only "significant" ones missing are Geronimo (that provides some shitty API of its own which would involve building against their stuff ... no thanks!), Oracle, and SAP.
You can now specify a PMF prop "org.jpox.jtaLocator" to select which one you want (and otherwise it will go through all available). You can also add on your own via JPOX extensions. It's also integrated into org.jpox.store.rdbms.JTATransaction too. Good luck :-) CVS has changes to this issue, you should check if it is works for you.
More changes will follow, since it will be implemented as JPA spec. We might have few extensions to what is in JPA spec Moving to beta-3 since beta-2 is released tomorrow and more changes are implied by the description
Comment from Guido originally raised as
Current implementation of isActive() is: public boolean isActive() { boolean isActive = super.isActive(); if( isActive ) { //do not join transaction if org.jpox.Transaction already started return true; } joinTransaction(); return isActive; } The following fragment causes a org.jpox.jdo.exceptions.TransactionNotActiveException on makePersistent() call PersistenceManager pm = pmf.getPersistenceManager(); ut.setTransactionTimeout(300); ut.begin(); Product product = new Product("Sony Discman", "A standard discman from Sony", 200.00); pm.makePersistent(product); Using the debugger it is clear that if boolean isActive = super.isActive(); returns false, the active JTA transaction is correctly joined with the call to joinTransaction(); that correctly toggles active flag to true in the superclass. unfortunately local method variable isActive is not updated so the result is still false. If I manually set isActive = true with the debugger I get the following exception when I call
the first makePersistent() in the following code snippet: PersistenceManagerFactory pmf = JDOHelper.getPersistenceManagerFactory("jpox12-jta.properties"); PersistenceManager pm = pmf.getPersistenceManager(); ut.setTransactionTimeout(300); ut.begin(); Product product = new Product("Sony Discman", "A standard discman from Sony", 200.00); System.out.println("makePersistent product"); pm.makePersistent(product); <------exception raised here makePersistent product javax.jdo.JDOException: Invalid state. Transaction has already started at org.jpox.jdo.JPOXJDOHelper.getJDOExceptionForJPOXException(JPOXJDOHelper.java:373) at org.jpox.AbstractPersistenceManager.jdoMakePersistent(AbstractPersistenceManager.java:589) at org.jpox.AbstractPersistenceManager.makePersistent(AbstractPersistenceManager.java:609) at org.jpox.tutorial.MainJpoxJta.main_direct(MainJpoxJta.java:222) at org.jpox.tutorial.MainJpoxJta.main(MainJpoxJta.java:53) NestedThrowablesStackTrace: Invalid state. Transaction has already started org.jpox.transaction.JPOXTransactionException: Invalid state. Transaction has already started at org.jpox.transaction.TransactionManager.begin(TransactionManager.java:41) at org.jpox.TransactionImpl.begin(TransactionImpl.java:110) at org.jpox.jdo.JDOTransaction.begin(JDOTransaction.java:70) at org.jpox.store.rdbms.SchemaAutoStarter.open(SchemaAutoStarter.java:135) at org.jpox.store.rdbms.RDBMSManager$ClassAdder.rollbackSchemaCreation(RDBMSManager.java:3527) at org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTablesAndValidate(RDBMSManager.java:3652) at org.jpox.store.rdbms.RDBMSManager$ClassAdder.run(RDBMSManager.java:2810) at org.jpox.store.rdbms.RDBMSManager$MgmtTransaction.execute(RDBMSManager.java:2687) at org.jpox.store.rdbms.RDBMSManager.addClasses(RDBMSManager.java:854) at org.jpox.store.StoreManager.addClass(StoreManager.java:617) at org.jpox.store.StoreManager.getDatastoreClass(StoreManager.java:1322) at org.jpox.state.JDOStateManagerImpl.populateStrategyFields(JDOStateManagerImpl.java:615) at org.jpox.state.JDOStateManagerImpl.initialiseForPersistentNew(JDOStateManagerImpl.java:368) at org.jpox.state.StateManagerFactory.newStateManagerForPersistentNew(StateManagerFactory.java:120) at org.jpox.ObjectManagerImpl.persistObjectInternal(ObjectManagerImpl.java:1101) at org.jpox.ObjectManagerImpl.persistObject(ObjectManagerImpl.java:1002) at org.jpox.AbstractPersistenceManager.jdoMakePersistent(AbstractPersistenceManager.java:584) at org.jpox.AbstractPersistenceManager.makePersistent(AbstractPersistenceManager.java:609) at org.jpox.tutorial.MainJpoxJta.main_direct(MainJpoxJta.java:222) at org.jpox.tutorial.MainJpoxJta.main(MainJpoxJta.java:53) This is an issue with the new SchemaAutoStarter. In this case it should start a new new transaction in a different thread.
Disabling auto starter makes me go further.
There is still the problem of isActive() implementation. Is it possible to fix in a next snapshot ? Moved to next release since no comment on the status of this
Jorg is clearly not working on this, so unassigned
Check the CVS version. Guido test case works for me....
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Closed
Major
Use of JPOX with JTA using JNDI without requiring JCA
Is now localised, and linked in via RDBMSManager (using transactionType PMF property).
Does this mean this issue is complete ?