openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryl Stultz <>
Subject Re: EntityManager used in multiple threads
Date Fri, 18 Sep 2009 12:14:19 GMT
On Fri, Sep 18, 2009 at 3:47 AM, Prodoc <> wrote:

> How would one implement the re-fetching?

Suppose you have a list of entites. You click one row which gets the
selected entity and calls a "doEdit" method passing in the entity:

public void doEdit(Entity e) {
   e = getEntityManager().find(Entity.class, e.getId());

This approach will allow lazy loading, if I want eager, I'll write a query
with fetches. This approach assumes a different em for each transaction. If
you are using one and only one em, e would be the same instance before and
after the find(). In my case, the above also allows me to bind the entity to
the GUI for editing without changing values in the entity in the list view
(so the editing could be cancelled).

Can this be done in a transparent
> way? One would not want to have to consider 'should I re-fetch the object
> or
> not?' before each use of the object.

I imagine there's a way to make it pretty easy but probably not

The only thing I can come up with is e.g. check if a property is 'null' when
> its getter is called and if so re-fetch the object. This, however, will
> cause re-fetching being done in a lot of cases where it isn't required
> since
> a property could be actually 'null' just as well, thus slowing down the
> application unnecessary.

As well, you'd keep replacing the entity, so if you've bound the entity to
something, you can't re-fetch it (think "final Entity e..."). I have access
to unloaded properties disabled so I don' accidently misinterpret null

is there a way to

refer to the object to retrieve again in the same way as using 'this' within
> an object?

No, you can't "refresh" an instance - only replace it. You'd have to write
code in your entity to replace all its properties with those from another

I now see your follow up regarding the factory. If you are still pursuing
the multi-threaded em problem, you might consider wrapping the em and
synchronizing access to the delegate. Not knowing how often multi-threaded
access to the em will occur, it's hard to say what kind of bottleneck this
will be.

Daryl Stultz
6 Degrees Software and Consulting, Inc.

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