You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xmlbeans.apache.org by David Bau <da...@bea.com> on 2003/09/29 17:27:07 UTC

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/


Re: V2 Store discussion...

Posted by Don Ferguson <do...@bea.com>.
As you may already know, finalizers must be used with extreme caution.  
Because they are run by in the GC thread (when all other threads are 
paused) if a finalizer deadlocks, the entire VM will be frozen.  This 
makes using synchronization in a finalizer particularly dangerous.  
There are also problems around any operations that allocate memory in a 
finalizer.

(Note: my information may be out of date).

    -Don

David Bau wrote:

>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/


Re: V2 Store discussion...

Posted by Don Ferguson <do...@bea.com>.
As you may already know, finalizers must be used with extreme caution.  
Because they are run by in the GC thread (when all other threads are 
paused) if a finalizer deadlocks, the entire VM will be frozen.  This 
makes using synchronization in a finalizer particularly dangerous.  
There are also problems around any operations that allocate memory in a 
finalizer.

(Note: my information may be out of date).

    -Don

David Bau wrote:

>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/


Re: [xmlbeans-dev] RE: V2 Store discussion...

Posted by David Bau <da...@bea.com>.
----- Original Message ----- 
From: "Chris Fry" <ch...@bea.com>


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

+1

Makes sense.  Or if not a 2nd implementation, then some other way to make
the synchronization cost optional.  We'd probably want to be fast by
default.  I agree that most usage is single-threaded.  And if your perf is
bad, people will avoid your whole API, and then thread safety will be a moot
point.

D


- ---------------------------------------------------------------------
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/


Re: [xmlbeans-dev] RE: V2 Store discussion...

Posted by David Bau <da...@bea.com>.
----- Original Message ----- 
From: "Chris Fry" <ch...@bea.com>


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

+1

Makes sense.  Or if not a 2nd implementation, then some other way to make
the synchronization cost optional.  We'd probably want to be fast by
default.  I agree that most usage is single-threaded.  And if your perf is
bad, people will avoid your whole API, and then thread safety will be a moot
point.

D


- ---------------------------------------------------------------------
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/


RE: V2 Store discussion...

Posted by Chris Fry <ch...@bea.com>.
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/


RE: V2 Store discussion...

Posted by Chris Fry <ch...@bea.com>.
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/