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 transactions.
hth, mark -----Original Message----- From: Thomas Fischer [mailto:[EMAIL PROTECTED] Sent: Monday, December 06, 2004 3:19 AM To: Apache Torque Users List Subject: RE: Best Practices for read-only operations and concurrency? 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] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
