[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal: New XML Storage Engine
On Mon, 14 Aug 2000, Lars Martin wrote:
> Hi Zvi,
>
> thanks for your fast reply.
>
> On Sam, 12 Aug 2000, Zvi wrote:
> > looks similar to GMD-IPSI PDOM implemetation. Only they using Index of clusters,
> > instead of your scheme, where each cluster points to next cluster.
> > Each node can be identified by Number-of-Cluster in the document and Number-of-Node
> > in the cluster.
>
> Uhh, from where did you get such internal information about GMD-IPSI? Is there
> any whitepaper out there? Are these information available for public?
>
> Anyway, we have try to adapt ozones architecture. And ozone uses cluster for
> object pooling - so we now have ozone clusters containing node clusters. This
> fits much more better into the ozone architecture then thousands of individual
> nodes.
>
> BTW: It is not written anywhere that one may not copy good ideas. ;-)
>
> > There are will be issues of grabage collection - you can not delete Cluster, until at
> > least one node used.
>
> You are right. But the underlaying storage backend is responsible for doing it
> in the most clever way. ;-)
>
> > Also this violate Ozone policy of "object never leave server", b/c Cluster will not
> > live inside server, but wrappers for individual nodes will live on client side.
>
> You saw your mistake already. ;-)
>
> > How transactions will be implemented? Per-node or per-cluster?
>
> Do you mean locks? Normally I would say 'per-cluster' but this highly depends
> on the underlaying storage backend - wizard-store or something else. This
> underlaying storage backend is responsible for locking. I think Falko can
> explain this much better ...
The storage back end of ozone is responsible to implement the actual lock
policy. The WizardStore (the only storage backend available today) collects
database objects in clusters. A lock is set for the entire cluster. Since the
node clusters are database objects all nodes from the cluster and all other
objects of the same WizardStore cluster are locked.
I decided to go this way because acquiring locks is _the_ hotspot of ozone
(except for actually loading/storing). Having one lock per cluster is much
faster because checking if a object/cluster is already locked is way faster
then actually acquiring the lock. I needed this performance to make ozone able
to handle XML data. XML nodes are very small objects and ozone wasn't designed
to deal with such small objects from the beginning. Acquiring one lock for each
XML node would be much slower than the current solution.
Falko
--
______________________________________________________________________
Falko Braeutigam mailto:falko@smb-tec.com
SMB GmbH http://www.smb-tec.com