aspose file tools*
The moose likes JDBC and the fly likes JDBC Transaction beginning Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » JDBC
Bookmark "JDBC Transaction beginning" Watch "JDBC Transaction beginning" New topic
Author

JDBC Transaction beginning

scott miles
Ranch Hand

Joined: Jun 16, 2011
Posts: 70
In JDBC can we say the transaction begins as soon as we get the connection and finishes as we close the connection. IS this right? If yes can we say In different requests sharing the same connection, even all the uncommitted transactions will be visible to all all requests?
Scott Selikoff
author
Saloon Keeper

Joined: Oct 23, 2005
Posts: 3710
    
    5

No, it depends if autocommit is enabled on the connection.


My Blog: Down Home Country Coding with Scott Selikoff
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42292
    
  64
I'd say the TX begins as soon as the first SQL statement is sent over the connection (assuming that setAutoCommit(false) has been called). It ends when commit() or rollback() is called. If the connection is closed without calling either, rollback() is automatically called.

There is only ever a single active transaction per connection at any given time, so I don't understand the second part of the question.


Ping & DNS - my free Android networking tools app
scott miles
Ranch Hand

Joined: Jun 16, 2011
Posts: 70
Ulf Dittmer wrote:I'd say the TX begins as soon as the first SQL statement is sent over the connection (assuming that setAutoCommit(false) has been called). It ends when commit() or rollback() is called. If the connection is closed without calling either, rollback() is automatically called.

You mean transaction begin with the execution query. Right?

There is only ever a single active transaction per connection at any given time, so I don't understand the second part of the question.


What i am asking here is , say some request get connection and update the customer table .But its not commited yet. If another request comes and get the same connection will updation of customer table by request1 will be visible to request2??? Looks like from your answer second transaction also will be treated as continuation of first one like we have propagation_required in spring/EJB . Is this right?
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42292
    
  64
I'm not familiar with what Spring does, but at any given time there is at most one TX open per connection. For that reason, it's not a good idea to share connections between threads (which is what I assume you mean by "requests").
scott miles
Ranch Hand

Joined: Jun 16, 2011
Posts: 70
Thanks Ulf for bearing me. Connection sharing across the requests is not a good design . Thats correct. But i am asking this question to get the better understanding of transaction handling .Let me rephrase my question

Request1 get connection say 1 and update the customer table .But its not commited yet. If another request say Request2 comes and get the same connection will updation of customer table by request1 .

Both the transaction done by request1 and request2 will be considered as one active transaction associated with connect1. Correct?

Updates done by request1 will be visible to request2. Right?
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42292
    
  64
I repeat: there can be at most one TX per connection at a given time. Saying "Both the transaction done by request1 and request2" is incorrect, as there will be just one TX.

Why are you wondering about what happens if a connection is shared between requests if you already know that you should not be doing that if you want correct results?
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: JDBC Transaction beginning