• Bug
  • Status: Closed
  • 2 Major
  • Resolution: As Designed
  • Byte Code Transform,Sessions
  • cdennis
  • Reporter: teck
  • December 10, 2008
  • 0
  • Watchers: 0
  • April 10, 2009
  • February 10, 2009

Attachments

Description

When a value is being lazily faulted in a java.util.Hashtable, the top level synchronization is still being held. This means that all operations on the hashtable will be blocked. This is particularly bad since our clustered HttpSession manager and ConcurrentStringMap use Hashtable underneath them.

The attached threads demonstrate the problematic locking.

Ideally we should not hold any locks while faulting like HashMap does

Comments

Alex Miller 2009-01-21

for Quintara

Chris Dennis 2009-01-27

I have coded a fix and associated test, but it is yet to be verified that the synchronization changes haven’t created any potential data races.

Saravanan Subbiah 2009-02-02

Tim forward me the changes, here are a couple of things I want to mention.

1) If Hashtable is not autolocked, then there is an external DSO lock that is controlling access to the Hashtable. So this optimization will not give any benefit since the external lock is still held when the objects are faulted. This is the reason it was only done for get() in the first place.

I understand that it is still beneficial to CSM since external locks are different for different keys. Just wanted to note that the optimization will not work in general hashtable case.

2) If Hashtable is autolocked, then faulting outside the scope of DSO lock has the potential to race and result in Object Not Found exception coz, another node could remove the object that is being faulted and that object could be GCed. Of course this is a race case, but still a possible case.

Chris Dennis 2009-02-09

In light of Saro’s comment, I’m proposing we resolve as “As Designed”.

Regarding CSM, it seems a custom collection implementation to replace Hashtable may be the best solution.

Chris Dennis 2009-02-10

Not a bug… see previous comments.