Deepa,
Deepa Singh wrote On 10/31/05 13:33,:
> Between my first run and second run, I dropped the table and constraints
> associated with them, and then re-created the table to make sure
> database is in clean condition for successive runs
Was the app still up and running while you were in recreating the
tables? If yes, such activities are possible if the persistence
runtime does not use the cached data.
Tom, Gordon,
Is there a way to bypass the cache and always talk to the database
directly?
>
> I looked up spec's Chapter 3 "Entity Operations" to understand "persist"
> "detached" state and "flush" operations and still not clear.
persist operations explicitly says that detached instances
can't be persisted.
> I put EntityManager.flush( ) before persist method calls, and still
> seeing same behaviour
I think your persist() call fails because the backend verifies
if it already knows about this PK for this entity type. As it caches
all data, the instance is found (as detached), and persist fails
right away.
flush() won't change anything.
>
> If I undeploy the application , deploy again and then run the client
> after cleaning up database, then there are no exceptions, and PERSIST
> operation suceeds.
Yes, because now you have a new ClassLoader, and as a result a new
Class for this PK.
thanks,
-marina
>
>
>
> Marina Vatkina wrote:
>
>>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
>