• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

JDBC Transaction beginning

 
scott miles
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4028
18
Eclipse IDE Flex Google Web Toolkit
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No, it depends if autocommit is enabled on the connection.
 
Ulf Dittmer
Rancher
Posts: 42968
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
scott miles
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Rancher
Posts: 42968
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Rancher
Posts: 42968
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Consider Paul's rocket mass heater.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic