Hi Shouldn't be possible since it would assume this flow:
thread1. start tx | thread2. - thread1. create the entry | thread2. - thread1. serialize the entry | thread2. - thread1. commit tx | thread2. - find the entry thread1. | thread2. - fails The commit will happen in org.apache.openejb.server.cxf.ejb.EjbMethodInvoker#invoke where the serialization happens after in org.apache.cxf.jaxb.io.DataWriterImpl#write(java.lang.Object, org.apache.cxf.service.model.MessagePartInfo, T) Only case it should be possible to happen is if you wrapped jaxws servlet/layer with a custom transaction management (through a filter for instance) which would start/commit outside default JAXWS handling. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2017-04-26 12:59 GMT+02:00 Paul Carter-Brown < [email protected]>: > Hi > > I have a call flow as follows in tomee: > > 1. Client calls jaxws service that adds a row into mysql table. EJB is > using JTA with eclipselink JPA entity bean. Seevice returns the primary key > of the row just added. > 2. Client uses returned soap message that contains the primary key and > calls a second service that does a select for the row in question. > > The service in 1 and 2 is in the same tomee instance and caching in jpa is > disabled. Tx isolation isread committed. > > Under high load and concurrency doing about 1000 tps i get about a 20% > failure rate where the service at stage 2 cannot find the row inserted at > stage 1. The row is inserted at some stage as i do see it in the db. Its as > though service 1 is returning prior to the database having committed the > data. My understanding is that this should not be possible as it would > create all sorts of inconsistencies. Is what i am observing expected > behaviour? > > Paul > > Sent from my phone. Message may be brief and contain typos. > > -- > > > This email is subject to the disclaimer of Smile Communications at > http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/ > disclaimer> > >
