Mailing-List: contact xmlbeans-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: xmlbeans-dev@xml.apache.org
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: V2 Store discussion...
Date: Mon, 29 Sep 2003 11:31:23 -0700
Message-ID: <4B2B4C417991364996F035E1EE39E2E11E9D74@uskiex01.amer.bea.com>
Thread-Topic: V2 Store discussion...
Thread-Index: AcOGt1JGnC/fKvzFRl+BqbhJLU6XpAAAB1qQ
From: "Eric Vasilik" <ericvas@bea.com>
To: <xmlbeans-dev@xml.apache.org>, <christopher.fry@bea.com>

But Collections is thread safe for read operations, yes?  I assume those =
bold letters said that access must be externally synchronized when =
modifying a collection.  If this is the case, then users have come to =
expect that read operations are thread safe.  This is the assumption we =
are considering breaking.

- Eric

-----Original Message-----
From: Patrick Calahan [mailto:pcal@bea.com]
Sent: Monday, September 29, 2003 11:24 AM
To: xmlbeans-dev@xml.apache.org; christopher.fry@bea.com; =
xmlbeans-dev@xml.apache.org
Subject: RE: V2 Store discussion...


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=20

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

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.

-p


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. =20

Any thoughts?  Any confusion about this trade off? =20

- Eric

-----Original Message-----
From: Chris Fry [mailto:christopher.fry@bea.com]
Sent: Monday, September 29, 2003 9:55 AM
To: xmlbeans-dev@xml.apache.org; 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...

-C

> -----Original Message-----
> From: David Bau [mailto:david.bau@bea.com]
> Sent: Monday, September 29, 2003 8:27 AM
> To: Eric Vasilik
> Cc: xmlbeans-dev@xml.apache.org
> 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:   xmlbeans-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
> Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
>
>


- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/

- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/