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 18:35:31 GMT
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