Bill Burke wrote: > A BMP findByPrimaryKey is optimized to look in cache first for the active > pk. If it is active in cache, then the pk is just returned, without calling > ejbFindByPrimaryKey on the BMP. Should we do this for commit-options 'B' > and 'C'? > > Here's the scenario somebody just submitted as a bug. They get a BMP (so > it's active in cash). They manually delete the bean through straight JDBC > (not calling bean.remove()). Then findByPrimaryKey(pk) returns a valid > Entity when the entity is actually deleted in the DB. Maybe for commit > option b and c we should not do this optimization? > > Same for CMP?
With a create, JBossCMP executes a query to check if the new entity already exists, but I think even if it were inserted correctly, we would get an inserting an already existing entity exception when the container attempts to insert the new key into the cache. We could assume that if the create executes successfully and the key is already in the cache, the current value in the cache is out-of-date and just drop it. -dain _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
