custom transactions

[Woodchuck <wo...@yahoo.com>]

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!



		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

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

Re: custom transactions

[Brett Connor <br...@spamcop.net>]

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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org