You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Dain Sundstrom <da...@iq80.com> on 2007/04/08 09:17:51 UTC
Can I reuse instances?
Is it possible to reuse instances from transaction to transaction?
I would like to be able to create a bean in one transaction, detach
it and reattach the same instance in a new transaction. My goal here
is specifically to reuse instances across transactions because they
have a very expensive creation cost, and no I can not redesign the
system.
I tried a quick test case using merge, but merge returned a new
instance:
beginTx();
Employee dain = entityManager.find(Employee.class, dainPk);
assertEquals(dain.getFirstName(), "Dain");
commitTx();
beginTx();
assertSame(dain, entityManager.merge(dain));
assertEquals(david.getFirstName(), "Dain");
commitTx();
When I try to use the refresh method, OpenJPA complains that the
entity "is not managed by this context".
So is there anyway for me to reuse instances?
-dain
Re: Can I reuse instances?
Posted by Dain Sundstrom <da...@iq80.com>.
On Apr 10, 2007, at 1:24 PM, Craig L Russell wrote:
> Hi Dain,
>
> On Apr 10, 2007, at 12:58 PM, Dain Sundstrom wrote:
>
>> On Apr 9, 2007, at 5:44 PM, Craig L Russell wrote:
>>
>>> 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.
>>
>> In my implementation the CMP entity is the JPA entity. They are
>> the same object. There are no "state holders".
>
> Now I understand. I don't think the design works, from lots of
> different perspectives.
>
>> We choose this design to easy the transition from CMP to JPA but
>> has the drawback that we are completely reliant on the JPA
>> implementation for instance management.
>
> I don't think the design can work. The CMP protocol requires
> separating the CMP instance from its state. You are generating the
> CMP concrete implementation class as part of deployment, and the
> concrete class needs to contain state or a reference to state. My
> experience is that keeping state directly in the CMP bean isn't
> likely to work well.
>
> Sorry for the distracting comments. I didn't imagine that you were
> trying to directly persist CMP beans.
I can assure the design "works".
-dain
Re: Can I reuse instances?
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Dain,
On Apr 10, 2007, at 12:58 PM, Dain Sundstrom wrote:
> On Apr 9, 2007, at 5:44 PM, Craig L Russell wrote:
>
>> 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.
>
> In my implementation the CMP entity is the JPA entity. They are
> the same object. There are no "state holders".
Now I understand. I don't think the design works, from lots of
different perspectives.
> We choose this design to easy the transition from CMP to JPA but
> has the drawback that we are completely reliant on the JPA
> implementation for instance management.
I don't think the design can work. The CMP protocol requires
separating the CMP instance from its state. You are generating the
CMP concrete implementation class as part of deployment, and the
concrete class needs to contain state or a reference to state. My
experience is that keeping state directly in the CMP bean isn't
likely to work well.
Sorry for the distracting comments. I didn't imagine that you were
trying to directly persist CMP beans.
Craig
>
> -dain
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Can I reuse instances?
Posted by Dain Sundstrom <da...@iq80.com>.
On Apr 9, 2007, at 5:44 PM, Craig L Russell wrote:
> 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.
In my implementation the CMP entity is the JPA entity. They are the
same object. There are no "state holders". We choose this design to
easy the transition from CMP to JPA but has the drawback that we are
completely reliant on the JPA implementation for instance management.
-dain
RE: Can I reuse instances?
Posted by Patrick Linskey <pl...@bea.com>.
> 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: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
> 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:Craig.Russell@sun.com
> 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.
Re: Can I reuse instances?
Posted by Craig L Russell <Cr...@Sun.COM>.
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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Can I reuse instances?
Posted by Dain Sundstrom <da...@iq80.com>.
On Apr 9, 2007, at 12:41 PM, Patrick Linskey wrote:
>> 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.
>
> ... but it's not the JPA-visible itself that is necessarily going
> to be
> heavyweight, these days. Maybe the proxies shepherding the instance
> through the CMP lifecycle will be heavyweight, or certain fields in
> the
> instance sourced from JNDI.
>
> My point is that if you're seeing a performance penalty from creating
> the actual instances themselves, I'd be interested in knowing what it
> is, because potentially we could address that problem directly. If the
> penalty is some other parts of the instantiation process, or the
> fetching of the data from the database, well, that could be less
> resolvable.
When a CMP instance is created there are two callbacks
setEntityContext (the entity now exists) and activate (the entity now
has a primary key). Both of these callbacks are allowed to lookup
stuff in JNDI like EJBs and JDBC connections. Some applications
cache lots of data and some even cache data from databases. So it
could be very expensive.
For most apps, these callbacks are empty.
> How are you coding the interaction between the (oh-so-wonderfully-
> named)
> commit options and the JPA data cache?
I'm not because my implementation didn't work. I tried to implement
them by keeping cache of instances. Then when an instance if
fetched, I would check the global cache, and if there was an instance
available, I would call merge. Then if commit option B, I would do a
refresh (reload?). The problem was that merge returned a new
instance making my global cache useless.
-dain
RE: Can I reuse instances?
Posted by Patrick Linskey <pl...@bea.com>.
> 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.
... but it's not the JPA-visible itself that is necessarily going to be
heavyweight, these days. Maybe the proxies shepherding the instance
through the CMP lifecycle will be heavyweight, or certain fields in the
instance sourced from JNDI.
My point is that if you're seeing a performance penalty from creating
the actual instances themselves, I'd be interested in knowing what it
is, because potentially we could address that problem directly. If the
penalty is some other parts of the instantiation process, or the
fetching of the data from the database, well, that could be less
resolvable.
How are you coding the interaction between the (oh-so-wonderfully-named)
commit options and the JPA data cache?
-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: Dain Sundstrom [mailto:dain@iq80.com]
> Sent: Monday, April 09, 2007 11:11 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: Can I reuse instances?
>
> 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.
>
> -dain
>
>
>
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.
Re: Can I reuse instances?
Posted by Dain Sundstrom <da...@iq80.com>.
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.
-dain
Re: Can I reuse instances?
Posted by Craig L Russell <Cr...@Sun.COM>.
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.
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.
Craig
On Apr 8, 2007, at 1:15 PM, Dain Sundstrom wrote:
> Thanks for the great info Patrick.
>
> For now, I'm going to leave my implementation the way it is,
> without instance reuse, and wait until someone complains loudly.
>
> BTW in CMP there are a several places in the lifecycle of entities
> that people like to reuse beans...
>
> 1) Beans are created and the ejb context is set into them
> 2) A primary key is assigned
> 3) Data is loaded into the bean
>
> People like to reuse instances at all three levels. The solution
> you suggest below addresses the first. Would it be possible to
> hook the cache to give the OpenJPA system an entity with data
> already loaded?
>
> Anyway, for not I'm just going to wait and see if anyone deeply
> cares about this feature.
>
> Thanks for help,
>
> -dain
>
> On Apr 8, 2007, at 8:56 AM, Patrick Linskey wrote:
>
>> Hi,
>>
>> The easy way to do this is with extended persistence contexts. In an
>> extended persistence context, your working set of objects lasts
>> for the
>> duration of the entity manager, not the transaction.
>>
>> In a JTA environment, the container is supposed to set things up
>> so that
>> EMs are transactional by default. To the best of my knowledge,
>> between
>> this rule and the persistence context propagation rule, this means
>> that
>> the container creates an EM proxy that gets injected / looked up, and
>> that internally delegates through to the "right" EM internally. (I'm
>> assuming that you're doing this for your EJB2 container work.)
>>
>> So, going with an extended PC is probably not sufficient for you,
>> if you
>> want to be spec-compliant. One thing that you could do, though, is
>> make
>> your EM proxy smart about holding onto a single EM for a long
>> amount of
>> time for use in transactions, but only use that EM during
>> transactions.
>>
>> This would be closer to spec-compliant behavior, but wouldn't be 100%
>> there.
>>
>> The 100% solution would be to change OpenJPA to delegate to a
>> pluggable
>> factory for creation of new instances. This would require creating an
>> interface with the two pcNewInstance() signatures in
>> PersistenceCapable,
>> and changing the nine places in code that use that method directly to
>> call the factory instead.
>>
>> Then, you could plug in whatever instance pooling logic you
>> prefer, and
>> you'd be in good shape. You'd need to figure out some way to know
>> when
>> to re-pool the instances, but in a container environment, that
>> shouldn't
>> be that hard. Note that you wouldn't want to use an
>> Synchronization.afterCompletion() callback, since if it's
>> detached, the
>> instance might be used after completion in a rendering step or
>> something
>> of the sort, or it might be tucked away in session state for use
>> later
>> on.
>>
>> Of course, if you've got a pluggable instance factory, you'd have
>> some
>> other alternates as well, such as creating clones or something of the
>> sort.
>>
>> Out of curiosity, what is slow about creating your instances?
>>
>> -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: Dain Sundstrom [mailto:dain@iq80.com]
>>> Sent: Sunday, April 08, 2007 12:18 AM
>>> To: open-jpa-dev@incubator.apache.org
>>> Subject: Can I reuse instances?
>>>
>>> Is it possible to reuse instances from transaction to transaction?
>>>
>>> I would like to be able to create a bean in one transaction, detach
>>> it and reattach the same instance in a new transaction. My
>>> goal here
>>> is specifically to reuse instances across transactions because they
>>> have a very expensive creation cost, and no I can not redesign the
>>> system.
>>>
>>> I tried a quick test case using merge, but merge returned a new
>>> instance:
>>>
>>> beginTx();
>>> Employee dain = entityManager.find(Employee.class, dainPk);
>>> assertEquals(dain.getFirstName(), "Dain");
>>> commitTx();
>>>
>>> beginTx();
>>> assertSame(dain, entityManager.merge(dain));
>>> assertEquals(david.getFirstName(), "Dain");
>>> commitTx();
>>>
>>> When I try to use the refresh method, OpenJPA complains that the
>>> entity "is not managed by this context".
>>>
>>> So is there anyway for me to reuse instances?
>>>
>>> -dain
>>>
>>
>> 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.
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Can I reuse instances?
Posted by Dain Sundstrom <da...@iq80.com>.
Thanks for the great info Patrick.
For now, I'm going to leave my implementation the way it is, without
instance reuse, and wait until someone complains loudly.
BTW in CMP there are a several places in the lifecycle of entities
that people like to reuse beans...
1) Beans are created and the ejb context is set into them
2) A primary key is assigned
3) Data is loaded into the bean
People like to reuse instances at all three levels. The solution you
suggest below addresses the first. Would it be possible to hook the
cache to give the OpenJPA system an entity with data already loaded?
Anyway, for not I'm just going to wait and see if anyone deeply cares
about this feature.
Thanks for help,
-dain
On Apr 8, 2007, at 8:56 AM, Patrick Linskey wrote:
> Hi,
>
> The easy way to do this is with extended persistence contexts. In an
> extended persistence context, your working set of objects lasts for
> the
> duration of the entity manager, not the transaction.
>
> In a JTA environment, the container is supposed to set things up so
> that
> EMs are transactional by default. To the best of my knowledge, between
> this rule and the persistence context propagation rule, this means
> that
> the container creates an EM proxy that gets injected / looked up, and
> that internally delegates through to the "right" EM internally. (I'm
> assuming that you're doing this for your EJB2 container work.)
>
> So, going with an extended PC is probably not sufficient for you,
> if you
> want to be spec-compliant. One thing that you could do, though, is
> make
> your EM proxy smart about holding onto a single EM for a long
> amount of
> time for use in transactions, but only use that EM during
> transactions.
>
> This would be closer to spec-compliant behavior, but wouldn't be 100%
> there.
>
> The 100% solution would be to change OpenJPA to delegate to a
> pluggable
> factory for creation of new instances. This would require creating an
> interface with the two pcNewInstance() signatures in
> PersistenceCapable,
> and changing the nine places in code that use that method directly to
> call the factory instead.
>
> Then, you could plug in whatever instance pooling logic you prefer,
> and
> you'd be in good shape. You'd need to figure out some way to know when
> to re-pool the instances, but in a container environment, that
> shouldn't
> be that hard. Note that you wouldn't want to use an
> Synchronization.afterCompletion() callback, since if it's detached,
> the
> instance might be used after completion in a rendering step or
> something
> of the sort, or it might be tucked away in session state for use later
> on.
>
> Of course, if you've got a pluggable instance factory, you'd have some
> other alternates as well, such as creating clones or something of the
> sort.
>
> Out of curiosity, what is slow about creating your instances?
>
> -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: Dain Sundstrom [mailto:dain@iq80.com]
>> Sent: Sunday, April 08, 2007 12:18 AM
>> To: open-jpa-dev@incubator.apache.org
>> Subject: Can I reuse instances?
>>
>> Is it possible to reuse instances from transaction to transaction?
>>
>> I would like to be able to create a bean in one transaction, detach
>> it and reattach the same instance in a new transaction. My
>> goal here
>> is specifically to reuse instances across transactions because they
>> have a very expensive creation cost, and no I can not redesign the
>> system.
>>
>> I tried a quick test case using merge, but merge returned a new
>> instance:
>>
>> beginTx();
>> Employee dain = entityManager.find(Employee.class, dainPk);
>> assertEquals(dain.getFirstName(), "Dain");
>> commitTx();
>>
>> beginTx();
>> assertSame(dain, entityManager.merge(dain));
>> assertEquals(david.getFirstName(), "Dain");
>> commitTx();
>>
>> When I try to use the refresh method, OpenJPA complains that the
>> entity "is not managed by this context".
>>
>> So is there anyway for me to reuse instances?
>>
>> -dain
>>
>
> 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.
RE: Can I reuse instances?
Posted by Patrick Linskey <pl...@bea.com>.
Hi,
The easy way to do this is with extended persistence contexts. In an
extended persistence context, your working set of objects lasts for the
duration of the entity manager, not the transaction.
In a JTA environment, the container is supposed to set things up so that
EMs are transactional by default. To the best of my knowledge, between
this rule and the persistence context propagation rule, this means that
the container creates an EM proxy that gets injected / looked up, and
that internally delegates through to the "right" EM internally. (I'm
assuming that you're doing this for your EJB2 container work.)
So, going with an extended PC is probably not sufficient for you, if you
want to be spec-compliant. One thing that you could do, though, is make
your EM proxy smart about holding onto a single EM for a long amount of
time for use in transactions, but only use that EM during transactions.
This would be closer to spec-compliant behavior, but wouldn't be 100%
there.
The 100% solution would be to change OpenJPA to delegate to a pluggable
factory for creation of new instances. This would require creating an
interface with the two pcNewInstance() signatures in PersistenceCapable,
and changing the nine places in code that use that method directly to
call the factory instead.
Then, you could plug in whatever instance pooling logic you prefer, and
you'd be in good shape. You'd need to figure out some way to know when
to re-pool the instances, but in a container environment, that shouldn't
be that hard. Note that you wouldn't want to use an
Synchronization.afterCompletion() callback, since if it's detached, the
instance might be used after completion in a rendering step or something
of the sort, or it might be tucked away in session state for use later
on.
Of course, if you've got a pluggable instance factory, you'd have some
other alternates as well, such as creating clones or something of the
sort.
Out of curiosity, what is slow about creating your instances?
-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: Dain Sundstrom [mailto:dain@iq80.com]
> Sent: Sunday, April 08, 2007 12:18 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: Can I reuse instances?
>
> Is it possible to reuse instances from transaction to transaction?
>
> I would like to be able to create a bean in one transaction, detach
> it and reattach the same instance in a new transaction. My
> goal here
> is specifically to reuse instances across transactions because they
> have a very expensive creation cost, and no I can not redesign the
> system.
>
> I tried a quick test case using merge, but merge returned a new
> instance:
>
> beginTx();
> Employee dain = entityManager.find(Employee.class, dainPk);
> assertEquals(dain.getFirstName(), "Dain");
> commitTx();
>
> beginTx();
> assertSame(dain, entityManager.merge(dain));
> assertEquals(david.getFirstName(), "Dain");
> commitTx();
>
> When I try to use the refresh method, OpenJPA complains that the
> entity "is not managed by this context".
>
> So is there anyway for me to reuse instances?
>
> -dain
>
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.
Re: Can I reuse instances?
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Dain,
On Apr 8, 2007, at 1:02 PM, Dain Sundstrom wrote:
> On Apr 8, 2007, at 10:20 AM, Craig L Russell wrote:
>
>> Hi Dain,
>>
>> On Apr 8, 2007, at 12:17 AM, Dain Sundstrom wrote:
>>
>>> Is it possible to reuse instances from transaction to transaction?
>>>
>>> I would like to be able to create a bean in one transaction,
>>> detach it and reattach the same instance in a new transaction.
>>> My goal here is specifically to reuse instances across
>>> transactions because they have a very expensive creation cost
>>
>> Do you have some reason to believe this? Entities are cheap.
>> They're not like CMP beans that are so expensive they need to be
>> pooled.
>
> You keep forgetting I'm using JPA to implement CMP :)
No, this is the same approach that Sun app server 7, 8, and 9 use.
I'm very aware of the issues. ;-)
Craig
>
> -dain
>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Can I reuse instances?
Posted by Dain Sundstrom <da...@iq80.com>.
On Apr 8, 2007, at 10:20 AM, Craig L Russell wrote:
> Hi Dain,
>
> On Apr 8, 2007, at 12:17 AM, Dain Sundstrom wrote:
>
>> Is it possible to reuse instances from transaction to transaction?
>>
>> I would like to be able to create a bean in one transaction,
>> detach it and reattach the same instance in a new transaction. My
>> goal here is specifically to reuse instances across transactions
>> because they have a very expensive creation cost
>
> Do you have some reason to believe this? Entities are cheap.
> They're not like CMP beans that are so expensive they need to be
> pooled.
You keep forgetting I'm using JPA to implement CMP :)
-dain
Re: Can I reuse instances?
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Dain,
On Apr 8, 2007, at 12:17 AM, Dain Sundstrom wrote:
> Is it possible to reuse instances from transaction to transaction?
>
> I would like to be able to create a bean in one transaction, detach
> it and reattach the same instance in a new transaction. My goal
> here is specifically to reuse instances across transactions because
> they have a very expensive creation cost
Do you have some reason to believe this? Entities are cheap. They're
not like CMP beans that are so expensive they need to be pooled.
Creating Entities from their second level cached versions (em.find)
should be cheaper than merging because merging requires iterating the
detached Entity and populating the transaction context Entity.
Getting an Entity from the second level cache is extremely efficient.
> , and no I can not redesign the system.
Which system are you referring to? If you're using Entities as the
backing persistent objects for CMP beans, there are lots of different
approaches...
Craig
>
> I tried a quick test case using merge, but merge returned a new
> instance:
>
> beginTx();
> Employee dain = entityManager.find(Employee.class, dainPk);
> assertEquals(dain.getFirstName(), "Dain");
> commitTx();
>
> beginTx();
> assertSame(dain, entityManager.merge(dain));
> assertEquals(david.getFirstName(), "Dain");
> commitTx();
>
> When I try to use the refresh method, OpenJPA complains that the
> entity "is not managed by this context".
>
> So is there anyway for me to reuse instances?
>
> -dain
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!