At 10:25 AM 9/29/2003 -0700, Eric Vasilik wrote:
Did the JDK make the map operations safe in the face of multiple threads doing operations which modify the map?   I

Yeah, early classes like java.util.Hashtable and Vector were internally synchronized with respect to reads and writes.

It may be interesting to note that when Collections came along, most of the classes came with a note in big bold letters that access to them must be externally synchronized.  Given that Collections has been very well-received and is probably the single most-used API in the JDK, I wonder how much of a requirement threadsafe XMLBeans really is going to be for users.


The problem I'm facing with the architecture of the store is one where it seems that I have to trade off synchronize/finalize with object creation.  I've found that creating fewer objects benefits performance, but renders read operations thread unsafe.

Dave and I talked this morning about this and we believe that performance of the store is so important that making the store thread safe (for read operations) will be optional and *off* by default. 

Any thoughts?  Any confusion about this trade off? 

- Eric

-----Original Message-----
From: Chris Fry []
Sent: Monday, September 29, 2003 9:55 AM
To:; Eric Vasilik
Subject: RE: V2 Store discussion...

I think you should be careful not to make the same mistakes that the JDK
made early on with the map implementations.  The early map implementations
were thread safe and very slow, so no-one used them.  It might be best to
have two implementations of the store (one that is thread safe & one that
isn't) so that users can choose safety over performance.  Or performance if
they know the data will only be read in a single thread as may be the case
in WS-invocations...


> -----Original Message-----
> From: David Bau []
> Sent: Monday, September 29, 2003 8:27 AM
> To: Eric Vasilik
> Cc:
> Subject: V2 Store discussion...
> Eric, was thinking about the threading/object creation etc
> issues over the
> weekend.
> Another interesting issue: currently we use a finalizer on
> cursors, but
> finalizers seem to be fairly expensive, so apps that spew out
> lots and lots
> of cursors have issues.  I wonder what problems we'd have to
> deal with in
> order to eliminate the finalizer, and whether or not that
> would be possible,
> or if it would come into conflict with some of the other
> parameters of the
> problem just like synchronization?
> David
> -
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> Apache XMLBeans Project -- URL:

- ---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
Apache XMLBeans Project -- URL: