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
<[email protected]>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 <[email protected]>:
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. <
[email protected]> 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. <
[email protected]> 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 <
[email protected]> 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. <
[email protected]> 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 <
[email protected]
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
[email protected]
https://twitter.com/AndyGeeDe
TomEE treibt Tomitribe! | http://tomee.apache.org
--
Andy Gumbrecht
http://www.tomitribe.com
[email protected]
https://twitter.com/AndyGeeDe
TomEE treibt Tomitribe! | http://tomee.apache.org
