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) 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 : Mosaic Marketing & Technology Solutions t. 416.977.2101 x. 529 http://www.mediumone.com/ __________________________________________________________ Think it. Build it. Work it. ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com ________________________________________________________________________
