> Your implementation uses JPA Entities to hold the state. These JPA > Entities are not at all specified by CMP Entity Beans. JPA Entities > as cheap to create so all you need to do is hold on to the ids and > when you need state from the database, ask JPA EntityManager for the > state. If the state is already in the second level cache, this is > very cheap to access.
I imagine that it's also possible that Dain's CMP entity beans are themselves the JPA entities, rather than beans that delegate on to a JPA entity. -Patrick -- Patrick Linskey BEA Systems, Inc. _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, April 09, 2007 5:45 PM > To: open-jpa-dev@incubator.apache.org > Subject: Re: Can I reuse instances? > > Hi Dain, > > On Apr 9, 2007, at 11:10 AM, Dain Sundstrom wrote: > > > On Apr 8, 2007, at 1:56 PM, Craig L Russell wrote: > > > >> Hi Dain, > >> > >> I haven't looked in detail at the life cycle of CMP beans in a > >> couple of years, but in general you can't simply keep the > state of > >> the underlying Entities through the life cycle. CMP beans are > >> pooled and reused in transaction contexts and you have to > load the > >> state at specific points in the life cycle. > > > > It depends on the commit option the container is using. In commit > > option A, you assume the cmp engine is the sole user of the > > database, so you don't need to load. Normally people use commit > > option B where you keep instances activated with a specific > primary > > key and reload the data in each tx. > > > >> Using the primary key stored in the CMP bean to do em.find at the > >> appropriate time is the obvious way to take advantage of the em > >> second level cache. To the extent that this is not efficient, we > >> should fix it in the JPA layer not the CMP layer. > > > > I would prefer to keep as much of the CMP stuff on the CMP side as > > possible so the JPA implementation can focus on JPA issues. One > > of the assumption of JPA is that entities are light weight and > > cheap to create, so you take the safe route and construct a > new one > > when every you need an instance. In CMP the assumption is that > > entity instances are expensive to create, so less safe route and > > you pool them. Reusing instances is really a CMP problem, but I > > don't think it can be implemented without the help of the > JPA engine. > > I'm afraid we're getting wrapped around the axle on definitions. > Here's what I'm trying to get across: > > CMP Entity Beans are expensive to create and there's a lot of > required behavior to manage them. You pretty much have to implement > the life cycle in the spec. It's your choice how to implement the > "state" part of the beans. You can use wrappers around various kinds > of state objects like ResultSet or generated classes that contain > fields with the state. > > Your implementation uses JPA Entities to hold the state. These JPA > Entities are not at all specified by CMP Entity Beans. JPA Entities > as cheap to create so all you need to do is hold on to the ids and > when you need state from the database, ask JPA EntityManager for the > state. If the state is already in the second level cache, this is > very cheap to access. > > Craig > > > > -dain > > > > > > Craig Russell > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > 408 276-5638 mailto:[EMAIL PROTECTED] > P.S. A good JDO? O, Gasp! > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
