Bugs item #551452, was opened at 2002-05-02 08:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=551452&group_id=22866
Category: JBossCMP Group: v2.4 (stable) >Status: Pending >Resolution: Invalid Priority: 5 Submitted By: Chris Harris (charris) >Assigned to: Scott M Stark (starksm) Summary: entity remove fails to clean cache Initial Comment: JBoss 2.4.5RC3-Jetty4.0.0 Windows 2K Sun JDK 1.3.1_03 This is similar to bug 463210 (http://sourceforge.net/tracker/index.php? func=detail&aid=463210&group_id=22866&atid=376685) except that I get failures when I try to remove entities and reinsert when using commit-option A or B. Using commit-option C it seems to work. Test case is attached as a deployable jar with source (test class is EntityRemoveCache245Test.class). Strange behaviour occurs from client code. If I do... 1. create entity with PK 1 2. do stuff on the entity (setXXX) 3. lookup entity (FBPK) and assign remote ref object to the results of that lookup 4. remove the entity through the looked-up ref 5. create entity with same PK (this is the 'testCreateAndRemoveFails') method in the test class) ...I get TRYING TO INSERT ALREADY EXISTING BEAN thrown at stage 5 -------------------------------------- [ScratchEntity] TRANSACTION ROLLBACK EXCEPTION: javax.transaction.TransactionRolledbackException: INSERTING AN ALREADY EXISTING BEAN, ID = [.1.]; ne sted exception is: java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.1.] java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = [.1.] at org.jboss.ejb.plugins.AbstractInstanceCache.insert (AbstractInstanceCache.java:218) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeH ome(EntityInstanceInterceptor.java :161) at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome (EntityLockInterceptor.java:97) at org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext (TxInterceptorCMT.java:142) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:347) at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome (TxInterceptorCMT.java:86) at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome (SecurityInterceptor.java:102) at org.jboss.ejb.plugins.LogInterceptor.invokeHome (LogInterceptor.java:103) at org.jboss.ejb.EntityContainer.invokeHome (EntityContainer.java:429) at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker. invokeHome(JRMPContainerInvoker.ja va:389) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch (UnicastServerRef.java:236) at sun.rmi.transport.Transport$1.run (Transport.java:147) at java.security.AccessController.doPrivileged (Native Method) at sun.rmi.transport.Transport.serviceCall (Transport.java:143) at sun.rmi.transport.tcp.TCPTransport.handleMessages (TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.ru n(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:479) -------------------------------- Yet if I replace stage 3 and 4 with 3. Create a new remote ref obj and assign the result of the FBPK to it 4. Delete the original entity through the original remote ref (this is 'testCreateAndRemoveSucceeds' method in the test class) It all works fine, regardless of commit-option. I've got a number of other problems all based around this, and all related to usage of findByPrimaryKey and remove(). Looks to me like it's being removed from the database (I've checked this v. thoroughly) but not from the cache. I've tried this with Hypersonic and with MSSQL with identical results. Note: this all works just fine in JBoss 2.4.4 ---------------------------------------------------------------------- >Comment By: Scott M Stark (starksm) Date: 2002-05-03 14:32 Message: Logged In: YES user_id=175228 The primary key class does not implement hashCode correctly with respect to Serialization. Here is a trival testcase: import java.rmi.MarshalledObject; import com.lombardrisk.scratch.ScratchEntityKey; public class TstKey { public static void main(String[] args) throws Exception { ScratchEntityKey pk1 = new ScratchEntityKey(1); System.out.println ("Integer.MIN_VALUE="+Integer.MIN_VALUE); System.out.println("pk1.hashCode="+pk1.hashCode()); MarshalledObject mo = new MarshalledObject(pk1); ScratchEntityKey pk2 = (ScratchEntityKey) mo.get(); System.out.println("pk2.hashCode="+pk2.hashCode()); } } Which when runs, shows that the unserialized object pk2 has a hashCode of 0: Integer.MIN_VALUE=-2147483648 pk1.hashCode=-2147483647 pk2.hashCode=0 Its basic Serializable stuff that default serialization does not execute the default constructor and member intializations during deserialization. In 2.4.5 we rely on the primary key's hashCode implementation if provided. Previous versions tried to be smarter in the user and in this case it would have worked. As to why one sequence works and one does not, I'm not yet sure, but fix your key and both methods work. ---------------------------------------------------------------------- Comment By: Chris Harris (charris) Date: 2002-05-03 01:11 Message: Logged In: YES user_id=8915 OK I tried a few distributions and got the following: N=failed, Y=succeeded commit-option dist A B C jboss244jetty317 Y Y Y jboss245rc1 N N Y jboss245rc2 N N Y jboss245rc3jetty400 N N Y All these test were done with default configuration, using Hypersonic as db. Only thing changed was the commit-option element in the Standard CMP EntityBean container- configuration in standardjboss.xml. In the cases where the test failed, the stack trace was identical to that posted in the original bug report. ---------------------------------------------------------------------- Comment By: Bill Burke (patriot1burke) Date: 2002-05-02 08:34 Message: Logged In: YES user_id=176497 can you verify with 2.4.5RC2? Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=551452&group_id=22866 _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
