In jbatch you can configure chunks, often helps Le 28 mars 2015 14:44, <[email protected]> a écrit :
> 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 >
