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