4 Replies Latest reply on Feb 18, 2004 3:18 AM by Carlo de Wolf

    Performance findByPrimaryKey & commit B

    Carlo de Wolf Master

      I saw that entity beans with commit B option on which I called findByPrimaryKey in a tx multiple times (don't ask why :-) ) each time resulted in a query to the db. According to EJB 2.0 spec it only needs to be synchronized at the start of tx. So as long as the entity is valid no find has to executed IMHO.

      I modified CMPPersistenceManager to follow suit:
      (this is a prototypical modification)

      __public Object findEntity(Method finderMethod, Object[] args, EntityEnterpriseContext ctx)
      ____throws Exception
      __{
      ____// For now only optimize fBPK
      ____if (finderMethod.getName().equals("findByPrimaryKey")
      ______ && commitOption != ConfigurationMetaData.C_COMMIT_OPTION)
      ____{
      ______Object key = ctx.getCacheKey();
      ______if (key == null)
      ______{
      ________key = ((EntityCache)con.getInstanceCache()).createCacheKey(args[0]);
      ______}
      ______if (con.getInstanceCache().isActive(key))
      ______{
      ________if(commitOption != ConfigurationMetaData.B_COMMIT_OPTION)
      ________{
      __________return key; // Object is active -> it exists -> no need to call finder
      ________}
      ________
      ________// ToDo: it's better to have a InstanceCache.isValid(key) because of synch
      ________EntityEnterpriseContext otherCtx = (EntityEnterpriseContext) con.getInstanceCache().get(key);
      ________if(otherCtx.isValid())
      ________{
      __________return key;
      ________}
      ______}
      ____}

      ____// The store will find the entity and return the primaryKey
      ____Object id = store.findEntity(finderMethod, args, ctx);

      ____// We return the cache key
      ____return ((EntityCache) con.getInstanceCache()).createCacheKey(id);
      __}

      Now I'm wondering what you guys think of this patch?