Torque and transactions

[Martin Schulz <ms...@dinmar.com>]

I am considering Torque for the implementation of a persistence layer for a
commerical product built on top a mature relational db.

I would like to obtain some feedback from the developer/designer community
on this topic.

A) Is Torque considered a full-featured persistence solution? If not, what's
missing? (Please don't flame... I'm serious)

B) How does Torque provide transactional services?  (Torque seems to
consider saving 'the tree' the transaction, but I couldn't find any
provisions to tie
    several such saves to a single transaction, for instance)

C) Are there any provisions for pessimistic or optimistic locking built into
or accessible using Torque?

D) I wrote up the following blurb to capture the high-level concept of what
Torque is doing for the user.  Please correct me if I went astray on this:

Torque supports the concept of an in-memory object tree (presumably exactly
those objects needed or modified by the user).  These objects are retrieved
from and
eventually saved back to a relational database, using statically generated
schema information and code.
The in-memory object tree can be considered ‘the cache’ and there’s no
further support for caching.  Following the same philosophy, the save method
saving all connected objects is considered ‘the transaction’.  No provisions
for concurrency management exists beyond this.

This puts the burden of concurrency management on the shoulder of the
developer. The system must make sure that:
-	modifications are always made through well-defined root-classes,
-	duplicate instantiation of the same objects has to be precluded by design.

Developers must understand how populating collections of dependant objects
and their modification affects the outcome when the result is saved.

Thanks

  Martin



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>