tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard W. Smith, Jr." <smithh032...@gmail.com>
Subject Re: question around entityManager.flush
Date Wed, 21 May 2014 14:58:35 GMT
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