[jboss-jira] [JBoss JIRA] Updated: (JBCACHE-947) Optimization in attach and detach; reduce calls to getPojo()

Jason T. Greene (JIRA) jira-events at lists.jboss.org
Mon Apr 2 20:03:13 EDT 2007


     [ http://jira.jboss.com/jira/browse/JBCACHE-947?page=all ]

Jason T. Greene updated JBCACHE-947:
------------------------------------

    Assignee: Jason T. Greene  (was: Ben Wang)

> Optimization in attach and detach; reduce calls to getPojo()
> ------------------------------------------------------------
>
>                 Key: JBCACHE-947
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-947
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: PojoCache
>            Reporter: Elias Ross
>         Assigned To: Jason T. Greene
>
> PojoCache.attach() calls getPojo() at least three times. Once in putObjectI() to determine if the existing object is the same as the attaching object (fairly rare condition), then once again in putObjectII() (which might be redundant.) Then, it calls detach() which calls getPojo() -- see below.
> I believe that simply calling pCache.detach() and returning the old value might be sufficient.
> Also, detach() likewise locates the object before removal, though the removal method itself returns the original object. This is because notification includes the original object before removal. In some cases, notification may not be required. It may also be better to refactor the notification listener so that every removal doesn't require two calls to "getPojo".
> I discovered this following the number of calls made in a profiler tool.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        



More information about the jboss-jira mailing list