Re: [bdbxml] .NET design questions
George Feinberg <[email protected]>
| Newsgroups | gmane.comp.db.dbxml.general |
|---|---|
| Message-ID | <[email protected]> |
On Jun 29, 2005, at 8:28 AM, Green, Spence wrote:
> All,
> I have a design question from the DBXML user perspective. I'm
> using managed c++, so I've written a managed wrapper around the
> core DBXML functionality. The wrapper queries the DB and then
> loads the results into the MS DOM. I commit the query transaction
> after loading the latter action. The higher software layers only
> see the DOM and perform all modifications on that object. Later, I
> transactionally commit the changes by using the object's ToString()
> method. This approach creates data hazards, though, as I will
> eventually have multiple processes accessing the database. Here
> are my questions:
>
> 1) How do I prevent data hazards (read after write, etc.).
> Currently I plan to implement my own locks. Is there a better
> solution?
At what granularity do you expect to lock? Document?
Are you specifically concerned with your users reading a modified
document in your
own layer before it's committed back?
> 2) Should I wait to commit the query transaction until AFTER I'm
> through with the data? I suppose this approach would prevent
> hazards to an extent.
If you are doing what amounts to a cycle of read-modify-write on a
document,
this makes sense. i.e.:
start transaction
read document
modify document
re-store document
commit transaction
If you do this, you need to make sure that errors
in your layer result in the transaction being either committed or
aborted, to
clean up.
> 3) Are there any other issues involved with multithreading the
> database?
It all depends on your concurrency requirements. Think hard about what
you want multiple processes to be able to do at the same time, and
design
around that.
If you want to provide cross-process locks in your application
at a higher semantic level than that provided by BDB XML
itself, the core Berkeley DB
API allows you to directly create/access locks that can be used
for other purposes:
http://www.sleepycat.com/xmldocs/ref/lock/nondb.html
George
>
> I would appreciate any comments. Thanks!
>
>
> Spence Green
> [email protected]
>
>
>
> ------------------------------------------
> To remove yourself from this list, send an
> email to [email protected]
>
>
------------------------------------------
To remove yourself from this list, send an
email to [email protected]