Woodchuck wrote:
hihi,
this is my scenario:
- container managed pooling (Tomcat 4.1.24)
- jdbc (PreparedStatement objects)
- wrapping my own transactions by autoCommit(false), and issuing
commit() manually
i'm running into a table-lock situation after DELETE statements. i'm
using the same Connection object for multiple PreparedStatement
objects. my plan is to call commit() at the end. but when i reach a
PreparedStatement that is doing a DELETE, the code stops and does not
continue with the rest of the other PreparedStatement objects.
is this the nature of DELETE statements? that we cannot continue
further without first committing it immediately? or is this possible
and there is something else wrong?
how can i handle a 'custom transaction' that contains many INSERTS,
UPDATES, DELETE statements in random order?
thanks in advance!
Woodchuck wrote:
hihi,
this is my scenario:
- container managed pooling (Tomcat 4.1.24)
- jdbc (PreparedStatement objects)
- wrapping my own transactions by autoCommit(false), and issuing
commit() manually
i'm running into a table-lock situation after DELETE statements. i'm
using the same Connection object for multiple PreparedStatement
objects. my plan is to call commit() at the end. but when i reach a
PreparedStatement that is doing a DELETE, the code stops and does not
continue with the rest of the other PreparedStatement objects.
is this the nature of DELETE statements? that we cannot continue
further without first committing it immediately? or is this possible
and there is something else wrong?
how can i handle a 'custom transaction' that contains many INSERTS,
UPDATES, DELETE statements in random order?
There is nothing fundamentally wrong with what you describe. If you have
conflicting locks or changes between transactions (typically
connections) then any DML statement can potentially hang up. What
database are you using? Are you testing it with just one session? My
first suspision would be the connection pooling, especially if this is
failing with only a single session active. Perhaps try disabling that
for a test.
HTH
Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
