Marina Vatkina wrote:
>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.
>
>
Yes. Application was still deployed and enabled while I was recreating
the tables
>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
>
>
Thanks for this information. I will put this in README at test level and
enable this test from top level and leave it as it is, until a better
way is found to run the test multiple times without undeploying application
>
>
>>
>>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
>>
>>
>>
>
>
>
--
Deepa Singh
Sun Java Enterprise System 9.0
J2EE Core
MailStop: USCA14-304
Santa Clara,CA
x40277 +1 408 404 5144