Hi, On Thu, Jan 22, 2009 at 11:36:42AM +0100, Alexander Klimetschek wrote: > On Thu, Jan 22, 2009 at 2:16 AM, Moritz Rebbert <[email protected]> > wrote: > > I created a stripped version where i was able to reproduce the Exception. > > > > My client Code looks like this: > > > > InitialContext ic = new InitialContext(); > > ItemTest test = (ItemTest) > > ic.lookup("item-state-ear-SNAPSHOT/ItemTestBean/remote"); > > for(int i = 1;i<10;i++){ //often occures the second or third > > time > > test.createFolder("folderA", false); > > test.createFolder("folderA/folderZ", false); > > test.remove("folderA", true); > > } > > Each call to createFolder() and remove() will be in its own > transaction, ie. concludes with a commit of the transaction, right? > (Sorry for the question, I am not familiar with the transaction > annotations) > Yes i hope so ;)
The EJB3 spec says: "REQUIRES_NEW The container must invoke an enterprise bean method whose transaction attribute is set to REQUIRES_NEW with a new transaction context. If the client invokes the enterprise bean’s method while the client is not associated with a transaction context, the container automatically starts a new transaction before delegating a method call to the enterprise bean business method. ... The container attempts to commit the transaction when the business method has completed." [0] So there is a new transaction for every remove() or createFolder(). I also had the same issues using BeanManagedTransaction, where I manually use a UserTransaction in any of this methods. The private methods within the Bean shouldn't starte a new Transaction because by default a method is implicitely annotated with REQUIRES, that uses an existing tx-context of the caller or creates a new one if such context does not exist. Regards Moritz [0]http://jcp.org/aboutJava/communityprocess/final/jsr220/index.html
