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 <agumbre...@tomitribe.com>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 > agumbre...@tomitribe.com > https://twitter.com/AndyGeeDe > > TomEE treibt Tomitribe! | http://tomee.apache.org > >
