[
https://jira.jboss.org/jira/browse/EJBTHREE-1897?page=com.atlassian.jira....
]
Paul Ferraro resolved EJBTHREE-1897.
------------------------------------
Resolution: Done
AS JBPAPP_5_0, Branch_5_x, and trunk now using version 2.2.15 of jboss-common-core
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