-
1. Re: Working my way up the stack
manik Apr 3, 2006 1:06 PM (in response to genman)Modified your original post to make it a bit more readable. :-)
-
2. Re: Working my way up the stack
manik Apr 3, 2006 1:08 PM (in response to genman)Re: #2, +1. Makes sense, certainly cleaner and eliminates the potential race cond.
-
3. Re: Working my way up the stack
manik Apr 3, 2006 1:17 PM (in response to genman)Re: #3,
+1 on caching Thread.currentThread() - the cost of this method call is not that great, but when it is done recursively it does add up - especially when it is so easy to fix.
+1 on the loop as well - an unnecessary complexity. Perhaps even a simpleIdentityLock[] locks = (IdentityLock[]) entry.getLocks().toArray(new IdentityLock[]{});
would do the trick -
4. Re: Working my way up the stack
genman Apr 3, 2006 7:33 PM (in response to genman)
How about items 1 and 4? -
5. Re: Working my way up the stack
manik Apr 4, 2006 8:13 AM (in response to genman)You'd want to hear back from Jerry Gauthier re. 4, who implemented the cache management interceptor.
-
6. Re: Working my way up the stack
manik Apr 4, 2006 8:14 AM (in response to genman)Re: 1, let me have a look and get back to you, although try disabling load attribs for these 2 cases and running the test suite.
-
7. Re: Working my way up the stack
jerrygauth Apr 4, 2006 10:16 AM (in response to genman)re: 4.
a) I think you're right on m_seq. The sequence number must be serialized so that clients can sort on it if necessary. It does seem that the current implementation might be susceptible to errors in a threaded environment.
The m_seq variable should also be redefined as a long (SynchronizedLong?) since this is what the Notification constructor specifies. It seems that I mistakenly defined it as an int.
b) The m_listeners variable is only used within a synchronized method so it appears to be ok as is.