Hello, thanks for your reply, so I understood async correctly then? It's not really a workaround but more about handling many trace rows yet keep the batch fast... I might skip async if I it does not help performance but I still want to be sure I understand how it works :)
I am using batchee and I am gonna refactor batch to be one single big transaction (now its one per thread) because entities getting detatched is killing performance. Not sure why we ended up with different transactions - did not write the code but I guess something in jsr352 will explain how to manage this. Actually a bit unsure about transactions and batches currently... Skickat från min iPhone > 28 mar 2015 kl. 13:40 skrev Romain Manni-Bucau <[email protected]>: > > Hi Karl > > You want requires new so use it. Would avoid issue if you refactor later > your code. > > What is the origin of the question? Why wanting to use a workaround? > Le 28 mars 2015 13:37, <[email protected]> a écrit : > >> Client transaction context does not propagate with an asynchronous method >> invocation. From the Bean Developer’s view, there is never a transaction >> context flowing in from the client. This means, for example, that the >> semantics of the REQUIRED transaction attribute on an asynchronous method >> are exactly the same as REQUIRES_NEW. >> >> Does this mean that when stateless calls async behavior is requries new >> but when async calls others behavior is normal? >> >> I have a long running batch step and when it fails and rollback it also >> rolls back failure traces we write in the db so I want it in a separate >> transaction so I figured async seems like nice fit but I am not sure if I >> need requires new or not? >> >> Cheers
