Deepa,
If this is a container-managed bean, the persistence context begins and
ends when the transaction begins and ends (see 5.6.2 in spec). A
detached entity is when it is not longer associated with a persistence
context. That's why it will work when the clean up method is within the
same runPersistenceTest method but not when it is a separate method. In
the clean up method, do a find on the entity prior to the remove; i.e.,
for (int i=1; i<7; i++ ) {Coffee newcoffee =
getEntityManager().find(Coffee.class, new Integer(i));
if (newcoffee != null ) {
getEntityManager().remove(newcoffee);
TLogger.log("removed coffee " + newcoffee);
}
}
Shelly
Deepa Singh wrote On 11/01/05 16:43,:
> Hi Gordon,
> Thanks a lot for clarifying cache issues.
> I tried clearing up database through EntityManager.remove() API and now
> running into some other issues. Please advice if my usage is incorrect
> Test is setup as follows:
> Appclient-->SessionBean-->Entities
>
> Session Bean has two separate business methods "runPersistenceTest"
> which populate the rows and "cleanUp" which deletes the row after
> calling EntityManager.remove()
>
> Populating the row goes on fine, but when I try to remove it, I am now
> getting exception,
> Caused by: java.lang.IllegalArgumentException: Entity must be managed to
> call remove: ID: 2: name :Betty: city :Sunnyvale, try merging the
> detatched and try the remove again.
> at
> oracle.toplink.essentials.publicinterface.UnitOfWork.performRemove(UnitOfWork.java:2692)
> at
> oracle.toplink.essentials.internal.ejb.cmp3.base.EntityManagerImpl.remove(EntityManagerImpl.java:117)
> at
> com.sun.enterprise.util.EntityManagerWrapper.remove(EntityManagerWrapper.java:171)
>
> at
> pe.ejb.ejb30.persistence.toplinksample.ejb.StatefulBean.cleanUp(StatefulBean.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
> Just to be extra sure, I am now calling EntityManager.merge () and then
> check if entity is in managed state by calling "contains". "contains"
> returns FALSE, and if I still call "remove" then I get above mentioned
> exception. I have specified a VERSION column as well for all three
> entities , and test is run on Derby datatabase All transaction
> attributes on session bean's business methods are Defaults which is
> "REQUIRED"
>
> If cleanUp () is called inside runPersistenceTest , then I am able to
> call entities.remove successfully. But if it is invoked as a separate
> business method from application client, then even after calling merge,
> entity is in detached state.
>
>
>
> Gordon Yorke wrote:
>
>>Marina,
>> TopLink is caching the data internally. Generally users have no issue with stale data (outside of the standard concurrency issues) but if the end user has processes modifying the data external to TopLink there are configuration options for handling the external updates. With the EJB 3.0 specification however there is no clear mechanism for providing support for configuring TopLink to handle externally modified data. We are currently evaluating our options and will hopefully have a solution soon.
>> In the meantime two options are available. Have the tests clear the objects from the database using the Persistence API or reset the TopLink caches by calling : ((oracle.toplink.essentials.ejb.cmp3.EntityManager)entityManager).getActiveSession().initializeAllIdentityMaps().
>>
>>--Gordon
>>
>>-----Original Message-----
>>From: Marina Vatkina [mailto:Marina.Vatkina_at_Sun.COM]
>>Sent: Monday, October 31, 2005 4:06 PM
>>To: Deepa Singh
>>Cc: Mitesh Meswani; Shelly (Donna) McGowan; Sanjeeb Kumar Sahoo; Michael
>>Bouschen; Sailaja Rao Gangaraju; persistence
>>Subject: Re: Persistence Test Integrated in QuickLook
>>
>>
>>Hi Deepa,
>>
>>(CC-ing persistence)
>>
>>Can it be that the record is already there? TopLink code might be
>>caching results of a previous run. Keep in mind that CMP code uses
>>completely different code for persistence runtime.
>>
>>thanks,
>>-marina
>>
>>Deepa Singh wrote On 10/31/05 12:52,:
>>
>>
>>>Hi Marina,
>>>Persistence Quicklook tests is integrated into GlassFish quicklook test
>>>base.
>>>glassfish/appserv-tests/sqetests/ejb/ejb30/persistence/onetomany
>>>
>>>There is only one thing missing, when I run my test (execute only client
>>>)twice (after dropping table and re-creating it), I get following
>>>exception in my server.log'. I don't see this exception when I run CMP
>>>2.1 tests in same mode. I deploy the ear file, and then execute
>>>appclient multiple times making sure that tests passes
>>>
>>>Caused by: java.lang.IllegalArgumentException: Can not PERSIST detatched
>>>object: pe.ejb.ejb30.persistence.toplinksample.ejb.CustomerEntity_at_f0ca71.
>>> at
>>>oracle.toplink.essentials.publicinterface.UnitOfWork.registerNewObjectForPersist(UnitOfWork.java:3131)
>>> at
>>>oracle.toplink.essentials.internal.ejb.cmp3.base.EntityManagerImpl.persist(EntityManagerImpl.java:96)
>>> at
>>>com.sun.enterprise.util.EntityManagerWrapper.persist(EntityManagerWrapper.java:163)
>>> at
>>>pe.ejb.ejb30.persistence.toplinksample.ejb.StatefulBean.runPersistenceTest(StatefulBean.java:25)
>>>
>>>Path is as follows:
>>>appclient-->stateful session-->persistence entities
>>>
>>>-stateful session has a method called runPersistenceTest. Please let me
>>>know how should I code this up,so that test passes after executing just
>>>client multiple times (cleaning up schema in between runs)
>>>
>>> public void runPersistenceTest(){
>>> CustomerEntity c1=new CustomerEntity(1,"Alice","Santa Clara");
>>> em.persist(c1);
>>> CustomerEntity c2=new CustomerEntity(2,"Betty","Sunnyvale");
>>> em.persist(c2);
>>> OrderEntity o1=new OrderEntity(100,1);
>>> em.persist(o1);
>>> OrderEntity o2=new OrderEntity(101,2);
>>> em.persist(o2);
>>> ItemEntity i1=new ItemEntity(100,"Camcorder");
>>> em.persist(i1);
>>> List result = em.createQuery("SELECT OBJECT(cust) FROM
>>>CustomerEntity cust").getResultList();
>>>
>>>
>>>
>>
>>
>>
>>
>
> --
> Deepa Singh
> Sun Java Enterprise System 9.0
> J2EE Core
> MailStop: USCA14-304
> Santa Clara,CA
> x40277 +1 408 404 5144
>