Hi,
Most databases nowadays support transactions (I have heard rumours that
even the new mysql versions do). So you can retrieve a connection, set its
transaction isolation, use the read(), save()... methods with your
connection, and then commit at the end. Depending which locking style your
database uses, concurrent access is handled differently: you get errors on
optimistic locking (e.g. used by oracle), and the data is locked on
pessimisitic locking. So the database handles the transactions for you, no
need to do it yourself. I use this strategy in a web application against
oracle myself, and I use serializable access on read and write transactions
except in very special cases. I use no framework on top, but feel free to
write a manager yourself.
Whether you want to use transactions on read operations, depends on how
strongly you need to read the same version of your data in your
transaction. Read the description of transaction levels in JDBC to decide
what you need.
Thomas
KeyofDMinor <[EMAIL PROTECTED]> schrieb am 03.12.2004 22:02:07:
>
> Hello all,
>
> I'm using Torque 3.1 in a multithreaded web app
> against Oracle 10g.
>
> The short version of my question is: is there a
> "read-only" transaction in Torque? The importance of a
> Transaction object for _writes_ is clear, but what
> about read-only operations?
>
> The long version: I do not have experience with
> Oracle; I have some experience with OO databases.
> With that background, I'm inclined to define a
> TransactionManager class which has two methods --
> read() and readwrite(). These methods would be
> synchronized so that writers do not interfere with
> readers. The readwrite() method would do a full
> transaction with commit/rollback etc. The read()
> method should -- in theory -- do a "lightweight" read
> of the database; a rollback is not necessary.
>
> Does this make sense in Torque? I realize that Oracle
> will isolate readers from writers. That is, until a
> writer commits, no one will see the changes. But I'm
> concerned about a concurrent read and write -- what if
> a writer commits during a long read operation? Am I
> being paranoid?
>
> The following code is my basic idea. In English: an
> Action interface encapsulates access to the database;
> the TransactionManager provides read() and write()
> methods which call the perform() method on the Action.
> In this way, the try-catch-commit-rollback paradigm
> can be centralized in one place. Also, there is
> strong serialization of DB access (though
> I realize this may be too much serialization!).
>
> Any comments? Again, I'm not sure if this is too
> strict. It feels like I'm rewriting a framework like
> Spring :-}
>
> thanks,
> Mike
> [EMAIL PROTECTED]
>
> ------------------------------------------------------
>
> interface Action {
> void perform();
> }
>
> class TransactionManager {
> public void readwrite(Action action) synchronized
> {
> Connection connection = null;
>
> try {
> connection = Transaction.begin(...);
> action.perform();
> Transaction.commit(connection);
> connection = null;
> } catch(TorqueException tex) {
> Transaction.rollback(connection);
> }
>
> // log success/fail and timing info
> }
>
> public void read(Action action) synchronized {
> // the "easy" way is to mimic readwrite()
> // but can we make this lightweight.
> // Should we even use a transaction here?
> }
> }
>
> class Example implements Action {
> public void run() {
> TransactionManager manager = ...;
> manager.read( this );
> }
>
> public void action() {
> Criteria c = new Criteria();
> c.add( stuff here );
> List results = SomePeer.doSelect( criteria );
> // populate Example with data from
> // results List
> }
> }
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - Easier than ever with enhanced search. Learn more.
> http://info.mail.yahoo.com/mail_250
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
