tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Louis Monteiro <jlmonte...@tomitribe.com>
Subject Re: question around entityManager.flush
Date Wed, 21 May 2014 09:21:12 GMT
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. <
smithh032772@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 <agumbrecht@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
> >   agumbrecht@tomitribe.com
> >   https://twitter.com/AndyGeeDe
> >
> >   TomEE treibt Tomitribe! | http://tomee.apache.org
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message