xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Calahan <p...@bea.com>
Subject Re: V2 store
Date Fri, 26 Sep 2003 22:00:58 GMT
At 04:42 PM 9/26/2003 -0400, David Bau wrote:

>(b) Dealing with very large instances (2) also seems to leads to "lazy
>object" created on demand.  For example, if the bulk of an 20GB instance is
>stored on disk, yet an app can hold on to an object that represents a node,
>then certainly not all nodes can be in memory at once.  They're created on

I'm not sure I agree that large payloads do necessarily lead us to lazy 
object creation.  In many (most?) cases, large payloads are large because 
they contain big chunks of base64 data, and those can be dealt with 

And in the case where someone really does have to bite off 20GB of 
structured XML data at once, I have to wonder if they aren't better served 
by writing directly to an API like 173.

(d) The upshot: it seems like
>- we need to synchronize at a low level to satisfy (4) at the same time as
>- to satisfy (3) - i.e., no synchronization cost, perhaps we should have a
>global option per instance to turn off synchronization; users can use this
>option if they are synchronizing themselves in a savvy mulithreaded app, or
>if they are truly single-threaded.
>That last bullet is a bit clumsy.  But I don't see anything better....

Agreed.  Maybe we could consider having separate synchronized and 
unsynchronized impls.  This would spare us the overhead of repeatedly 
checking a flag at runtime and might help keep the implementation more 
clean.  It obviously would result in more code, though, and at least a 
little redundancy.

In any event, though, maybe we could just defer the question of 
synchronization until later?  It seems like it would be easier to just get 
going on an unsynchronized impl, and than come back and see where we need 
to lock it down in order to provide a threadsafe one.


View raw message