well, there are several questions in your question. servlets can participate in transactions by obtaining UserTransaction from java:comp/UserTransaction from JNDI. you can .begin() on this transaction in first invocation of the servlet and .commit() or .rollback() on subsequent invocations of the servlet. you do not even need to store UserTransaction to the session or anything like that, you simply get the UserTransaction from the JNDI, start the transaction in one method, then again get the transaction from JNDI and commit/rollback transaction in another method in the servlet. however, problems can occur. if you need user input inbetween invocations, user can decide to not respond and you will lock the resource until the session times out. that is just one issue. you need to make sure that first invocation always preceeds second invocation because otherwise "Not In Transaction" Exception will the thrown on commit() invocation on UserTransaction. as far as locking the table(s) in the database, you need to set transaction isolation level such that table(s) is(are) locked until the transaction which uses them commits or rolls back. SERIALIZABLE is at the far end of transaction isolation levels since it is most restrictive and will always work, but it does not perform all that great since any table participating in a transaction will be locked for the duration of the transaction. another question you asked was whether you can re-use a connection between servlet invocations. you can try to store connection in the session and use it on subsequent servlet invocations. but beware that this may not always work. app server developers are given lots of freedom in how they implement certain things. if serialization is involved in app server's implementation of storing and retrieving session-bound objects, then the design will fail since Connection object is not serializable. i have had problems in the past with storing non-serializable objects into the session. just something to be aware of...