Andy, is there any sample code or blog or tomee test case that demonstrates your recommendation?
On Wed, May 21, 2014 at 11:37 AM, Andy Gumbrecht <[email protected]>wrote: > Which is why I used the additional local EJB in the past, basically where > it 'feels' like a flush is being helpful replace the logic with a local > bean that does that unit of work. > Look up and call that bean method from the current method, if it completes > then the current method is safe to complete. An explicit flush in an EJB > context is 'usually' a hack. > > Andy. > > > On 21/05/2014 17:19, Jean-Louis Monteiro wrote: > >> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> > -- > Andy Gumbrecht > > http://www.tomitribe.com > [email protected] > https://twitter.com/AndyGeeDe > > TomEE treibt Tomitribe! | http://tomee.apache.org > >
