Hi Deepa,
When extended PersistenceContext is fully supported (Gordon, what's the
status on this?) you should be able to use Statefull SB to run 2 operations
with the same EM.
You can either do em.merge(o); em.remove(o); or o = em.find(...); em.remove(o);
If either of them is not working, it's a bug :)
thanks,
-marina
Deepa Singh wrote:
> 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
>