tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: question around entityManager.flush
Date Wed, 21 May 2014 18:42:03 GMT
@Stateless // or singletong
public class TxBean {
   @PersistenceContext EntityManager em;

    public void doSomeStuffAndCommit() {
        // em usage
    }
}


when exiting the method commit will trigger flush


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 20:35 GMT+02:00 Howard W. Smith, Jr. <smithh032772@gmail.com>:

> 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
> <agumbrecht@tomitribe.com>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
> >> <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
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>
> > --
> >   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