RE: TX Was Null
Hmm. You potentially have a good point about the transaction retries, I hadn't considered that. I wouldn't have expected the application server to retry with an application-level exception is thrown, though. Do you know that to be the case? I like to keep the validation within the OM for a stronger OOP design, wherein the objects cannot be loaded with invalid data. That said, I've had to make a number of tradeoffs for EJB already, this may be another. I've seen a number of postings where people put snapshots in the value objects, but when you get to that point, EJB just seems as if you're using it for a really clumsy persistence layer instead of true enterprise objects. Our validation helper classes are already re-usable, so I wouldn't gain much there. We also have a CompositeValidationException class with a map of validation errors--interesting to see you went with a similar approach. - Geoffrey : -Original Message- : From: Manuel De Jesus [mailto:[EMAIL PROTECTED]] : Sent: Tuesday, January 29, 2002 2:11 AM : To: Orion-Interest : Subject: RE: TX Was Null : : : I don't think that relying on your Entity Beans for front line data : validation is a good design. As a rule of thumb to get the : best performance : in applications you want to validate as early as you can to : save the trouble : of having to process all the steps for a transaction only to : find the data : is invalid when you want to save things and use this to throw : an error. In : most app servers you usaully set transaction retries to at : least 2 (incase : there was a network/temporary error on the first attempt this : increases the : reliablity) - by throwing data validation exceptions at the : EJB level you : are looking at doing a TX twice before reporting the error : ... terrible : performance. : : What I have done in projects is to abstract validation to a set of : Validation classes that are normal java classes which can : be used on the : jsp/ejb etc etc tier. These classes interact with the : database via singleton : caches allowing for dynamic validation updates (worth their : weight in gold). : This also means that the stand alone validation objects can : be easily reused : in other projects, expecially the rules that are generic enough :). : : Using a separate set of validation classes I would suggest: : 1) Validate the TX at the point where it starts right up : front if you are : using jsp etc if this is an option. : 2) Validate the TX in the actual session bean. We use a : custom exception : with a Vector of string mappings that allows us to complain : about more than : one error etc. : 3) If you are really paranoid/have mutiple update points you can also : validate at the entity bean and even a littel at the db level : (not null, : size etc). : : Since you are using a shared validation library, changing the : validation is : done in one place. In addition your application = 100 times : faster since you : are not rolling back transactions a million times over. And : the big bonus is : it will work on 99% of app servers. : : Regards, : Manuel : : : -Original Message- : From: [EMAIL PROTECTED] : [mailto:[EMAIL PROTECTED]]On Behalf Of : [EMAIL PROTECTED] : Sent: Monday, January 28, 2002 5:13 PM : To: Orion-Interest : Cc: [EMAIL PROTECTED] : Subject: TX Was Null : : : We're coming up on our deployment date, so we're considering : our deployment : options (notably, at this point, JBoss and Orion). : : The system is running and working under JBoss, and I've been : re-porting it : to Orion so that we can do some testing, try and resolve some : issues we had : under Orion (for which we got some help from Atlassian that : we haven't had a : chance to try out yet). In the process, we've re-adjusted : most or all of : the finders, and fixed a few bugs here and there between what : JBoss does and : what Orion does. It's been enlightening, as usual. : : That said, we've run up against a brick wall. One of our : transactional : saves uses a session bean to save two entities in a combined : declarative : transaction. Each of these beans can throw validation exceptions when : passed data that's meant to save. We have two unit tests, : one which throws : invalid data into the first object, and another which throws : invalid data : into the second object. : : The second object is relatively easy -- if it has problems, : the session bean : sets the transaction to rollback only, and lets the server do : the rest of : the work. This works under both Orion and JBoss as expected. : : If the first object fails, though, there are larger issues -- : we still want : to find out if there's a problem with the data being passed : to the second : object. Under JBoss, if we tried to do this in the same : transaction, it : complained that the transaction was already rolled back, : which is sensible. : So we put the validation method into a 'requires new' transaction
TX Was Null
We're coming up on our deployment date, so we're considering our deployment options (notably, at this point, JBoss and Orion). The system is running and working under JBoss, and I've been re-porting it to Orion so that we can do some testing, try and resolve some issues we had under Orion (for which we got some help from Atlassian that we haven't had a chance to try out yet). In the process, we've re-adjusted most or all of the finders, and fixed a few bugs here and there between what JBoss does and what Orion does. It's been enlightening, as usual. That said, we've run up against a brick wall. One of our transactional saves uses a session bean to save two entities in a combined declarative transaction. Each of these beans can throw validation exceptions when passed data that's meant to save. We have two unit tests, one which throws invalid data into the first object, and another which throws invalid data into the second object. The second object is relatively easy -- if it has problems, the session bean sets the transaction to rollback only, and lets the server do the rest of the work. This works under both Orion and JBoss as expected. If the first object fails, though, there are larger issues -- we still want to find out if there's a problem with the data being passed to the second object. Under JBoss, if we tried to do this in the same transaction, it complained that the transaction was already rolled back, which is sensible. So we put the validation method into a 'requires new' transaction. On JBoss, if the first object fails, the second one tests its data in a new transaction, gathers the validation errors, and rolls back. On Orion, this seems to create an exception: Testcase: testProgramRollback took 4.703 sec Caused an ERROR Transaction was rolled back: Error in transaction: java.lang.InternalError: TX was null; nested exception is: java.lang.InternalError: TX was null com.evermind.server.rmi.OrionRemoteException: Transaction was rolled back: Error in transaction: java.lang.InternalError: TX was null at TransactionalSaver_StatelessSessionBeanWrapper176.saveProgramAndCaseStudy(Tr ansactionalSaver_StatelessSessionBeanWrapper176.java:104) at java.lang.reflect.Method.invoke(Native Method) at com.evermind._dh._gc(Unknown Source) at com.evermind._if.run(Unknown Source) at connection to localhost/127.0.0.1 as thesquareUser at com.evermind._cd.EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(Unknown Source) at com.evermind._cd.invokeMethod(Unknown Source) at com.evermind._dn.invoke(Unknown Source) at __Proxy7.saveProgramAndCaseStudy(Unknown Source) at com.mediumone.thesquare.ejb.transactionalSaver.liveTest.TransactionalSaverTe st.testProgramRollback(TransactionalSaverTest.java:69) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:166) at junit.framework.TestCase.runBare(TestCase.java:140) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:131) at junit.framework.TestSuite.runTest(TestSuite.java:173) at junit.framework.TestSuite.run(TestSuite.java:168) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRu nner.java:231) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestR unner.java:409) Nested exception is: java.lang.InternalError: TX was null at com.evermind.server.ejb.EntityEJBObject.endTransaction(Unknown Source) at com.evermind.server.ApplicationServerTransactionSynchronization._vib(Unknown Source) at com.evermind.server.ApplicationServerTransaction._vib(Unknown Source) at com.evermind.server.ApplicationServerTransactionSynchronization.afterComplet ion(Unknown Source) at com.evermind.server.ApplicationServerTransaction._end(Unknown Source) at com.evermind.server.ApplicationServerTransaction.end(Unknown Source) at TransactionalSaver_StatelessSessionBeanWrapper176.saveProgramAndCaseStudy(Tr ansactionalSaver_StatelessSessionBeanWrapper176.java:100) at java.lang.reflect.Method.invoke(Native Method) at com.evermind._dh._gc(Unknown Source) at com.evermind._if.run(Unknown Source) at connection to localhost/127.0.0.1 at com.evermind.server.rmi.OrionRemoteException._os(Unknown Source) at com.evermind._cd._mx(Unknown Source) at com.evermind._cd.run(Unknown Source) at java.lang.Thread.run(Thread.java:484) I'm basically unable to diagnose why this error would occur. Does anyone have any suggestions? - Geoffrey __ Geoffrey Wiseman: Internet Applications Manager Medium One
RE: TX Was Null
I don't think that relying on your Entity Beans for front line data validation is a good design. As a rule of thumb to get the best performance in applications you want to validate as early as you can to save the trouble of having to process all the steps for a transaction only to find the data is invalid when you want to save things and use this to throw an error. In most app servers you usaully set transaction retries to at least 2 (incase there was a network/temporary error on the first attempt this increases the reliablity) - by throwing data validation exceptions at the EJB level you are looking at doing a TX twice before reporting the error ... terrible performance. What I have done in projects is to abstract validation to a set of Validation classes that are normal java classes which can be used on the jsp/ejb etc etc tier. These classes interact with the database via singleton caches allowing for dynamic validation updates (worth their weight in gold). This also means that the stand alone validation objects can be easily reused in other projects, expecially the rules that are generic enough :). Using a separate set of validation classes I would suggest: 1) Validate the TX at the point where it starts right up front if you are using jsp etc if this is an option. 2) Validate the TX in the actual session bean. We use a custom exception with a Vector of string mappings that allows us to complain about more than one error etc. 3) If you are really paranoid/have mutiple update points you can also validate at the entity bean and even a littel at the db level (not null, size etc). Since you are using a shared validation library, changing the validation is done in one place. In addition your application = 100 times faster since you are not rolling back transactions a million times over. And the big bonus is it will work on 99% of app servers. Regards, Manuel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Monday, January 28, 2002 5:13 PM To: Orion-Interest Cc: [EMAIL PROTECTED] Subject: TX Was Null We're coming up on our deployment date, so we're considering our deployment options (notably, at this point, JBoss and Orion). The system is running and working under JBoss, and I've been re-porting it to Orion so that we can do some testing, try and resolve some issues we had under Orion (for which we got some help from Atlassian that we haven't had a chance to try out yet). In the process, we've re-adjusted most or all of the finders, and fixed a few bugs here and there between what JBoss does and what Orion does. It's been enlightening, as usual. That said, we've run up against a brick wall. One of our transactional saves uses a session bean to save two entities in a combined declarative transaction. Each of these beans can throw validation exceptions when passed data that's meant to save. We have two unit tests, one which throws invalid data into the first object, and another which throws invalid data into the second object. The second object is relatively easy -- if it has problems, the session bean sets the transaction to rollback only, and lets the server do the rest of the work. This works under both Orion and JBoss as expected. If the first object fails, though, there are larger issues -- we still want to find out if there's a problem with the data being passed to the second object. Under JBoss, if we tried to do this in the same transaction, it complained that the transaction was already rolled back, which is sensible. So we put the validation method into a 'requires new' transaction. On JBoss, if the first object fails, the second one tests its data in a new transaction, gathers the validation errors, and rolls back. On Orion, this seems to create an exception: Testcase: testProgramRollback took 4.703 sec Caused an ERROR Transaction was rolled back: Error in transaction: java.lang.InternalError: TX was null; nested exception is: java.lang.InternalError: TX was null com.evermind.server.rmi.OrionRemoteException: Transaction was rolled back: Error in transaction: java.lang.InternalError: TX was null at TransactionalSaver_StatelessSessionBeanWrapper176.saveProgramAndCaseStudy(Tr ansactionalSaver_StatelessSessionBeanWrapper176.java:104) at java.lang.reflect.Method.invoke(Native Method) at com.evermind._dh._gc(Unknown Source) at com.evermind._if.run(Unknown Source) at connection to localhost/127.0.0.1 as thesquareUser at com.evermind._cd.EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(Unknown Source) at com.evermind._cd.invokeMethod(Unknown Source) at com.evermind._dn.invoke(Unknown Source) at __Proxy7.saveProgramAndCaseStudy(Unknown Source) at com.mediumone.thesquare.ejb.transactionalSaver.liveTest.TransactionalSaverTe st.testProgramRollback(TransactionalSaverTest.java:69) at java.lang.reflect.Method.invoke(Native Method
Re: application client and EJB: TX was null
Dario Dorigo wrote: Hi, I'm testing Orion 1.3.8 with another EJB based application developed with weblogic. After a bit of pain I was able to connect to the ejb and to call the ejbs. But when I try to get the data from the ejb I've found what was the problem: in the ejb-jar.xml of the ejb there were: container-transaction method ejb-nameModuleManager/ejb-name method-intfRemote/method-intf method-name*/method-name /method trans-attributeRequired/trans-attribute /container-transaction /assembly-descriptor And that seems that is not accepted from an external client. bye (the method signature is: public String [] getListOfModules(); ) I got this error: java.lang.InternalError: TX was null at com.evermind.server.ejb.EntityEJBObject.endTransaction(JAX) at com.evermind.server.ApplicationServerTransaction.aob(JAX) at com.evermind.server.ApplicationServerTransaction.commit(JAX) at com.evermind.server.ApplicationServerTransaction.end(JAX) at ModuleManager_StatefulSessionBeanWrapper4.getListOfModules(ModuleManager_StatefulSessionBeanWrapper4.java:1062) at java.lang.reflect.Method.invoke(Native Method) at com.evermind.server.rmi.bd.run(JAX) at com.evermind.server.rmi.bb.hy(JAX) at com.evermind.server.rmi.bb.run(JAX) at com.evermind.util.f.run(JAX) at connection to pii/192.168.10.55 at com.evermind.server.rmi.OrionRemoteException.h2(JAX) at com.evermind.server.rmi.bb.hw(JAX) at com.evermind.server.rmi.bb.run(JAX) at java.lang.Thread.run(Thread.java:484) On the server side the ejb is a session bean that get (succesfully) the data from another entity bean. (I printed out the array just before the return) Has anybody an idea of what is happening? Thanks a lot Dario -- Dario Dorigo Software Developer [EMAIL PROTECTED] __ Itrade AG Net Market Systems Nymphenburger Str. 86 D - 80636 Muenchen Tel: +49/(0)89/18951-0, Fax: -199 Email: [EMAIL PROTECTED] http://www.itrade.ag _ -- Dario Dorigo Software Developer [EMAIL PROTECTED] __ Itrade AG Net Market Systems Nymphenburger Str. 86 D - 80636 Muenchen Tel: +49/(0)89/18951-0, Fax: -199 Email: [EMAIL PROTECTED] http://www.itrade.ag _
application client and EJB: TX was null
Hi, I'm testing Orion 1.3.8 with another EJB based application developed with weblogic. After a bit of pain I was able to connect to the ejb and to call the ejbs. But when I try to get the data from the ejb (the method signature is: public String [] getListOfModules(); ) I got this error: java.lang.InternalError: TX was null at com.evermind.server.ejb.EntityEJBObject.endTransaction(JAX) at com.evermind.server.ApplicationServerTransaction.aob(JAX) at com.evermind.server.ApplicationServerTransaction.commit(JAX) at com.evermind.server.ApplicationServerTransaction.end(JAX) at ModuleManager_StatefulSessionBeanWrapper4.getListOfModules(ModuleManager_StatefulSessionBeanWrapper4.java:1062) at java.lang.reflect.Method.invoke(Native Method) at com.evermind.server.rmi.bd.run(JAX) at com.evermind.server.rmi.bb.hy(JAX) at com.evermind.server.rmi.bb.run(JAX) at com.evermind.util.f.run(JAX) at connection to pii/192.168.10.55 at com.evermind.server.rmi.OrionRemoteException.h2(JAX) at com.evermind.server.rmi.bb.hw(JAX) at com.evermind.server.rmi.bb.run(JAX) at java.lang.Thread.run(Thread.java:484) On the server side the ejb is a session bean that get (succesfully) the data from another entity bean. (I printed out the array just before the return) Has anybody an idea of what is happening? Thanks a lot Dario -- Dario Dorigo Software Developer [EMAIL PROTECTED] __ Itrade AG Net Market Systems Nymphenburger Str. 86 D - 80636 Muenchen Tel: +49/(0)89/18951-0, Fax: -199 Email: [EMAIL PROTECTED] http://www.itrade.ag _
