Finding a XML-Database to fit our needs

[Ilya Sterin]

> Fine-granularity locking looks good on paper but the benefits can
> often be lost because you spend too much time doing lock acquisition/release
> and deadlock detection;

The same is true for relational databases and row level locking, but
most use it to achieve a particular level of consistency and
concurrency.

> in real workloads you can often achieve higher
> throughput by reducing the concurrency and the lock granularity,

Very true and with TigerLogic you have the ability to implicitly use
the most granular locking or explicitly specify any lock granularity
you would like.  The great thing, is that this can be done on per
transaction or per update operation, allowing you to define your
application semantics and utilize the least granularity needed per
operation.

> If
> you can avoid those mistakes, you may well find that document-level locking
> is actually quite good enough.

I disagree with this statement, though it might be that I tend to work
on more applications that require higher level of concurrency and
consistency than most.  I agree that depending on application or
use-case semantics, document level locking might just be good enough,
but my issue is that most xml db products these days only cater to
that requirement or a bit more granular.  Page level locking is more
granular, but now I must think it terms of pages and what data they
contain, though is indirect data chunking vs. working directly with my
data model to define these requirements.  I don't believe too many in
the relational world would settle for table level locks when row level
locks are appropriate, though most database products implicitly weight
the benefits of lower granularity of locks and performance and though
can implicitly upgrade locks, though this behavior can be overridden
explicitly through db specific apis.  In the native xml storage world
for some reason, most don't look at these as requirements for
enterprise grade storage.  I understand that most of today's use cases
encompass storing xml data chunks or data that does not meet the
concurrency requirements of a relational db, but I think that is
strictly a byproduct of the lack of products out there that support
the functionality to allow the xml storage model to be taken to the
next level.

Just my 2 cents.

Ilya

>
>
> Michael Kay
> http://www.saxonica.com/
>
>