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 15:19:59 GMT
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
<rmannibucau@gmail.com>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 <jlmonteiro@tomitribe.com>:
>
> > 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. <
> > smithh032772@gmail.com> 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. <
> > > smithh032772@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 <
> > > > jlmonteiro@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. <
> > > >> 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