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 < jlmonte...@tomitribe.com> 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. < > smithh032...@gmail.com> 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 < > 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 > > > > > > > > >
