tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Gumbrecht <agumbre...@tomitribe.com>
Subject Re: question around entityManager.flush
Date Wed, 21 May 2014 15:37:14 GMT
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
View raw message