you should have mentioned that before. Eclipselink is a bit special .... -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com
On Wed, May 21, 2014 at 8:16 AM, Romain Manni-Bucau <[email protected]>wrote: > cause eclipselink ;) > > > > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > 2014-05-21 17:11 GMT+02:00 Jean-Louis Monteiro <[email protected]>: > > > I don't see why, except if you are explicitly checking for database > > constraints in your code. > > Because, the default JDBC connection isolation level is READ COMMITTED > > AFAIR or REPEATABLE_READ for MySQL. > > > > Anyway, that means that you can never read uncommitted data. > > > > JLouis > > > > -- > > Jean-Louis Monteiro > > http://twitter.com/jlouismonteiro > > http://www.tomitribe.com > > > > > > On Wed, May 21, 2014 at 7:58 AM, Howard W. Smith, Jr. < > > [email protected]> wrote: > > > > > removing the manual/forced entityManager.flush() broke my app in a few > > > places. reverting to previous version and I may try to revisit this > > later. > > > :) > > > > > > > > > > > > On Wed, May 21, 2014 at 10:00 AM, Howard W. Smith, Jr. < > > > [email protected]> wrote: > > > > > > > Thanks Jean-Louis. Based on your response, i just commented out > > > > entityManager.flush() in my AbstractFacade.java for create, edit, and > > > > remove methods. > > > > > > > > i did some testing in my app, and seems to work well. will see how my > > app > > > > performs under load and when users are logged in and working, > > > concurrently. > > > > > > > > thanks again. > > > > > > > > > > > > > > > > On Wed, May 21, 2014 at 5:21 AM, Jean-Louis Monteiro < > > > > [email protected]> wrote: > > > > > > > >> As a general rule, I would recommend to never call flush(). The JPA > > > >> provider optimizing the flushing to avoid connections between the > > > >> Persistence Context and the rdbms. > > > >> > > > >> Of course at least at the end of the transaction (commit) the JPA > > > provider > > > >> flushes. > > > >> But for example, when you have a loop with search, read, update .... > > the > > > >> JPA provider is able to detect that there is a risk of dealing with > > > stale > > > >> object and will therefor flush as well. > > > >> > > > >> The only case I call flush is basically when as mentioned already, I > > > need > > > >> to check database constraints (Unique, etc). > > > >> The only reason is that I want to explicitly catch the exception > > either > > > to > > > >> ignore, retry, or rethrow using a business exception. > > > >> > > > >> Sometimes, I also use an ejb with a REQUIRES_NEW, so that the > current > > > >> transaction is suspended and a new one is created. Then, if an > > exception > > > >> occurs at commit time, I can catch in the current bean without > > changing > > > >> the > > > >> status of the current transaction. > > > >> > > > >> JLouis > > > >> > > > >> > > > >> > > > >> -- > > > >> Jean-Louis Monteiro > > > >> http://twitter.com/jlouismonteiro > > > >> http://www.tomitribe.com > > > >> > > > >> > > > >> On Mon, May 19, 2014 at 8:47 AM, Howard W. Smith, Jr. < > > > >> [email protected]> wrote: > > > >> > > > >> > Interesting question and answer. > > > >> > > > > >> > Per my 2+ year experience with Java EE 6, in my app, i used > NetBeans > > > to > > > >> > develop my JPA session facade (@EJB JPA DAO) classes, including > > > abstract > > > >> > class. In the abstract class, in the create and edit methods, I > did > > > add > > > >> > flush(), so after every create and edit JPA request, data is > written > > > >> > immediately. > > > >> > > > > >> > Honestly, I don't have any need to use @Scheduler or timer methods > > to > > > >> > ensure data is saved....successfully. > > > >> > > > > >> > In fact, I can maybe even remove flush(), but I have not done that > > > >> (yet). > > > >> > If I did remove flush() in my abstract class, then I would need to > > > test > > > >> the > > > >> > app, accordingly, to see the impact. > > > >> > > > > >> > I really don't see any performance issues with my > > > >> approach/implementation, > > > >> > but the app does not have many concurrent > > > >> > users/database-update-requests/etc. > > > >> > > > > >> > > > > >> > > > > >> > On Mon, May 19, 2014 at 4:02 AM, Andy Gumbrecht < > > > >> [email protected] > > > >> > >wrote: > > > >> > > > > >> > > Hi there Radhakrishna, > > > >> > > > > > >> > > > > > >> > > On 19/05/2014 08:15, Radhakrishna Kalyan wrote: > > > >> > > > > > >> > >> Hi, > > > >> > >> > > > >> > >> I have question around entityManager.flush(). > > > >> > >> Is it ok to call multiple times? Or will there be any > performance > > > >> issue. > > > >> > >> > > > >> > > Every time you hit the the database you will take a performance > > hit > > > >> back > > > >> > - > > > >> > > How much is impossible to say and is very dependant on what your > > app > > > >> is > > > >> > > doing. Just always think along the lines of 'how can I do this > > with > > > >> less' > > > >> > > and you'll be fine. > > > >> > > > > > >> > > > > > >> > >> My case is, I have a timer service which executes periodically > > > where > > > >> I > > > >> > >> create a database entity using a dao object using > > > >> > entityManager.persist(), > > > >> > >> after that I also call entityManager.flush(). > > > >> > >> > > > >> > >> The reason to do so is, if database commit fails due to certain > > > >> reason > > > >> > >> like > > > >> > >> unique constrain exception then I want the timer service to > send > > a > > > >> JMS > > > >> > >> message. > > > >> > >> > > > >> > > What you are doing is not necessarily wrong, but why not just > let > > > the > > > >> > > container do the work for you. The container managed > transactions > > > are > > > >> > your > > > >> > > friend. > > > >> > > > > > >> > > > > > >> > >> If I don't call entityManager.flush() then I am not able to > catch > > > any > > > >> > >> exception in my timer service thus fails to send any JMS > message. > > > >> > >> > > > >> > > In your service look up another local bean that handles the > > > >> persistence > > > >> > > and if required sends a message on success, this will all run > in > > a > > > >> > > transacted context - The success message will only be sent if > the > > > bean > > > >> > > method actually completes. > > > >> > > If the bean method call fails then you can catch the error and > do > > > the > > > >> > > extra leg work to send the 'fail' message. > > > >> > > > > > >> > > > > > >> > >> However at the end the database entity is never created which > is > > > >> > correct. > > > >> > >> But if I can't able to send the JMS message upon exception > then I > > > >> does > > > >> > not > > > >> > >> meet the requirement. > > > >> > >> > > > >> > >> Any ideas or recommendations to do it in a better way > > > >> > >> > > > >> > >> > > > >> > >> So I guess my suggestion is to not try and do all the work in > > the > > > >> timer > > > >> > > service method, rather call another bean method do do the work. > > > >> > > > > > >> > > Andy. > > > >> > > > > > >> > > -- > > > >> > > Andy Gumbrecht > > > >> > > > > > >> > > http://www.tomitribe.com > > > >> > > [email protected] > > > >> > > https://twitter.com/AndyGeeDe > > > >> > > > > > >> > > TomEE treibt Tomitribe! | http://tomee.apache.org > > > >> > > > > > >> > > > > > >> > > > > >> > > > > > > > > > > > > > >
