openejb-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Saint Croix" <>
Subject Re: Best practice for cascading persist of existing entity records
Date Tue, 22 Apr 2008 01:39:18 GMT
Thanks for the help, man.  I appreciate it.  The good news is that I don't
have multiple instances of units with the same values.  I use a static
factory to build units (such as kilogram), and make them available via
public static references from an SI class.

Forgetting units for a moment, let's say I have two entities.  Person and
Cheese.  I provide a static reference "Cheeses.SWISS" to a pre-built
instance of Cheese with the "name" field of the instance set to "swiss".
Then, I create Person bob = new Person("Bob", Cheeses.SWISS) and call

In my case, I've got a cascading PERSIST relationship between Person and
Cheese.  So, after the transaction, Cheeses.SWISS has an ID value.

Now, if I create Person alex = new Person("Alex", Cheeses.SWISS) and pass it
to mgr.persist(alex), I get a funny error about the primary key field
already having a value (sorry, I don't have the exact error text, but it's
easy to reproduce if it comes to that).

I gather from this that this isn't the best way to introduce new objects to
the persistence store when the objects reference data that is already in the
store.  I'm guessing that instead of this, there should be some kind of
transaction that gets the Cheese object from the datastore and then adds a
reference to it to the new Person object.  I think that pre-loading the SI
units into the datastore at the beginning makes a lot of sense.  Now I just
need some way to make sure that new entities that reference data already in
the datastore are correctly wired.  I'm wondering if there are examples of
this sort of thing?


On Mon, Apr 21, 2008 at 12:21 PM, Dain Sundstrom <> wrote:

> I'm not sure I fully understand what you are running into, but I'll take a
> stab at it.
> Normally, I suggest people avoid storing unit tables in the db, but in
> your specific case, I know you are have a persistence model for a truly
> generic system.  BUT, for anyone else reading this email in the archives, be
> careful with unit tables as you can get nasty locking problems.
> In your case, I would suggest, if at all possible, that you create and
> cache your unit objects in a separate "setup" transaction.  After the setup
> transaction, no one would add new units (in a production system valid units
> would be added by hand by an admin), so you would never have a cascade
> persist problem.
> As for your exact situation, I think the root cause of the problem is that
> you have multiple instances with the same value, say kilogram, in your
> object graph.  If instead all references refereed to the same object
> instance, you the key would only be generated once.  To test my theory,
> replace the Unit constructor with a static factory, and cache the instances
> you return.
> -dain
> On Apr 20, 2008, at 8:57 AM, Alexander Saint Croix wrote:
> > Howdy, all.
> >
> > I'm wondering what the best practice is for the following use case:
> >
> > I have a handful of entity classes, one of which is a Unit (such as
> > "kilogram") which has an auto-generated UID field.  Each individual
> > instance
> > of Unit ("kilogram", "second", "ampere", etc) can and will be used by
> > multiple instances of the other entity classes.
> >
> > The problem arises after I persist one of the unit instances (such as
> > "kilogram") and it is assigned a primary key field generated by the
> > container.  From that point forward, each other object that refers to
> > that
> > specific Unit instance gives me trouble when I try to persist it,
> > because it
> > already has a nonzero UID field value.
> >
> > Ideally, I do not want to have more than one "kilogram" record in the
> > "Unit"
> > table.  Is there a common practice to tell the persistence container to
> > "apply the persist cascade of the holding object to this field, unless
> > the
> > data represented by the field already exists in the database, in which
> > case
> > don't cascade--just reference the UID of that instance"?
> >
> > If the question isn't clear, I can provide sample code.  If you want to
> > punt
> > to the OpenJPA list, that's also acceptable.
> >
> > Cheers,
> > --
> > Alex
> >

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