db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <mark.a.g...@accenture.com>
Subject RE: Best Practices for read-only operations and concurrency?
Date Mon, 06 Dec 2004 13:54:23 GMT
Even if a writer commits during a long read operation Oracle will still
retain the session's read consistency. The mechanism Oracle uses for
read consistency utilizes the rollback segments and the one caveat for
this lies in the necessity for properly sizing rollback segments. If
they are too small, the information your read session requires for read
consistency can be overwritten and you get the well known "Snapshot too
old" error. In 9i however Oracle has gone to the use of undo segments
which the administrator can assign a lifetime rather than a finite size.
This can then be set to bracket the time frame for your longest running

hth, mark

-----Original Message-----
From: Thomas Fischer [mailto:Fischer@seitenbau.net] 
Sent: Monday, December 06, 2004 3:19 AM
To: Apache Torque Users List
Subject: RE: Best Practices for read-only operations and concurrency?


Most databases nowadays support transactions (I have heard rumours that
even the new mysql versions do). So you can retrieve a connection, set
transaction isolation, use the read(), save()... methods with your
connection, and then commit at the end. Depending which locking style
database uses, concurrent access is handled differently: you get errors
optimistic locking (e.g. used by oracle), and the data is locked on
pessimisitic locking.  So the database handles the transactions for you,
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
except in very special cases. I use no framework on top, but feel free
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
what you need.


KeyofDMinor <keyofdminor@yahoo.com> 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
> keyofdminor@yahoo.com
> ------------------------------------------------------
> 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: torque-user-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-user-help@db.apache.org

To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org

This message is for the designated recipient only and may contain privileged, proprietary,
or otherwise private information.  If you have received it in error, please notify the sender
immediately and delete the original.  Any other use of the email by you is prohibited.

To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org

View raw message