tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard W. Smith, Jr." <>
Subject Re: question around entityManager.flush
Date Mon, 19 May 2014 15:47:54 GMT
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

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

On Mon, May 19, 2014 at 4:02 AM, Andy Gumbrecht <>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
>   TomEE treibt Tomitribe! |

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