Danny wrote:What I was after was a way to build a list of transactions that are available to edit for a user.What I donít want in the list is any transactions that are currently being edited by another user.I think you should implement this notion of "transaction" within yourapplication, and be careful not to confuse it with the lower-levelDBMS concept of transaction.
That is, in your application, you should have a transaction table,and transactions should have a certain state, and a certain lifecycle,which you can define as appropriate for your application.Then, when a user is editing a transaction, you update the transactionstate in your transaction table to reflect that this transaction iscurrently being edited by this user.And, when you want to build a list of transactions which are notcurrently being edited, you run a select statement which fetchesthe rows from your transaction table which are in the appropriate state.thanks,bryanP.S. Regarding the low-level DBMS transaction, I agree with what othershave already said: keep them short and focused; don't hold them openacross UI think periods. Fetch some data from the database, update thingsas necessary to reflect that a user is currently working with this data,then commit that DBMS transaction. Later, when the user issues somecommand in the UI, use a separate DBMS transaction to return to thoserecords and process them accordingly.
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!