[jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1897) Improve handling of GUID as Fqn element in clustered SFSB

[Carlo de Wolf (JIRA)]

     [ https://jira.jboss.org/jira/browse/EJBTHREE-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf updated EJBTHREE-1897:
------------------------------------

    Fix Version/s: 1.1.18
                       (was: 1.1.16)


> Improve handling of GUID as Fqn element in clustered SFSB
> ---------------------------------------------------------
>
>                 Key: EJBTHREE-1897
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1897
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: cache, Clustering
>            Reporter: Brian Stansberry
>            Assignee: Paul Ferraro
>             Fix For: 1.1.18
>
>
> StatefulTreeCache uses the string representation of GUID as an element in an Fqn. Problem is GUID.toString() is very slow.  We need to optimize this
> One alternative is to use the GUID itself in the Fqn instead of the string. But, a test showed that a serialized GUID is 10x as big as the String (over 400 bytes bigger). And serializing/deserializing a GUID was ~ 5x more time consuming than the String. Hence the original use of the String.
> So, we need to optimize.
> One thing is to fix get() where it ends up calling GUID.toString() twice.
> Second is to find a way to cache the string so it gets created once per SFSB rather than once per get, release and replicate call.
> JBCOMMON-88 is to do that in the GUID class itself.  If we want to get this into EJB3 quicker than a new JBCOMMON release would allow we can evaluate using an org.ejb3 GUID subclass that caches the toString() result.

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