Hi Deepa,
On Nov 1, 2005, at 1:43 PM, 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.rem
> ove(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"
It sounds like you're using merge as a void operation. What merge
does is to create a copy and return the managed entity. It's the
returned entity that you can remove, not the detached instance.
>
> 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.
If cleanUp is called before transaction commit, then merge will
return the identical instance. So it works.
Craig
>
>
>
> 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.registerNewObje
>>> ctForPersist(UnitOfWork.java:3131)
>>> at
>>> oracle.toplink.essentials.internal.ejb.cmp3.base.EntityManagerImpl.p
>>> ersist(EntityManagerImpl.java:96)
>>> at
>>> com.sun.enterprise.util.EntityManagerWrapper.persist
>>> (EntityManagerWrapper.java:163)
>>> at
>>> pe.ejb.ejb30.persistence.toplinksample.ejb.StatefulBean.runPersisten
>>> ceTest(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