Entity Bean Rollback fails: caches are out of synch with the database

Question

We are encountering a critical issue where the rollback of a session transaction rolls back any database changes, but doesn't roll back bean changes in memory. When we next access the bean, it returns information that should have been rolled back. The memory cache is out of synch with the database.
We have a simple session bean S, using container managed transactions. We also have an entity bean E using bean managed persistence. E has a single member <name>.
We implement a method s() in S with <trans-attribute> Required as follows:
public void s() {
Context lookupContext = getLookupContext();
SHome shome = (SHome) lookupContext.lookup(SHome.NAME);
S s = shome.findByPrimaryKey(thePrimaryKey);
System.out.println("-- current name = " + s.getName());
s.setName("IGNORE");
EJBContext ejbContext = (EJBContext) getContext();
ejbContext.setRollbackOnly();
Since this is BMP, the setName call issues our SQL update against the S record. When the session transaction rolls back, the database changes are also rolled back. But the entity bean in memory shows the modified name. We can see this in the next call to s() since the getName() returns IGNORE rather than the original value. We have also gotten debugged into the underlying instance cache associated with the S bean descriptor. I.e.
AbstractEJBHome ejbHome = (AbstractEJBHome) lookupContext.lookup(SHome.NAME);
AlternateHashTable aht = ejbHome.getBeanDescriptor().getCache();
Looking at this map of bean instances also shows that the bean instance for S is not rolled back.
From previous conversations with the server technologies team, we understand that during the transaction, we should be working on a cloned copy of the S bean. Upon rollback, the copies should be discarded rather than merged back to the cached bean. They seem to be merged regardless of rollback state.
We are using OC4J 10.1.3.0.0 (build 060119.1546.05277).

Answer 1

Actually, what one or the developers in my group found out is two things:
1) The clone is a shallow copy.They copy the references but not objects themselves. This has been causing problems for us.
2) It seems that you don't work on a copy and you work on the original and they keep a copy. Now, this is fine IF you don't have multiple threads working on the same Entity bean and we moved our application from Weblogic where it throws an exception if that Entity bean is in use to OC4J which is suppose to copy the bean and doesn't so you have multiple threads possibly modifying the same object.