Difference between revisions of "WebSphere and locking issues"

From SybaseWiki
Jump to: navigation, search
 
m
Line 1: Line 1:
Using WebSphere on a Sybase ASE database can cause some issues with regard to locking in ASE. The default transaction isolation level for ASE is 1 (read committed). The default behaviour of WebSphere is to use isolation level 2 (repeatable read). This means that rows that are read will be kept locked until the transaction has finished. In turn, this will can lead to quite high change of sessions locking each other or the need to raise to ASE configuration parameter "number of locks" to a very high number (1 million is not uncommon).
+
Using WebSphere on a Sybase ASE database can cause some problems with regard to locking in ASE. The default transaction isolation level for ASE is 1 (read committed), however the default behaviour of WebSphere is to use isolation level 2 (repeatable read). This has the effect that even rows that are read will be kept locked until the transaction has finished. In turn, this can lead to a high change of sessions blocking each other or the need to raise to ASE configuration parameter "number of locks" to a very high number (more than 1 million is not uncommon).
 
To resolve this the WebSphere developers need to override the isolation level.
 
To resolve this the WebSphere developers need to override the isolation level.
  
Line 7: Line 7:
 
  dbcc pss(0,<spid>)
 
  dbcc pss(0,<spid>)
 
  go
 
  go
 
 
Look in the output for value after "pisolation" (somewhere halfway in the output).
 
Look in the output for value after "pisolation" (somewhere halfway in the output).
  
 
[[Category:ASE]]
 
[[Category:ASE]]

Revision as of 15:17, 17 March 2006

Using WebSphere on a Sybase ASE database can cause some problems with regard to locking in ASE. The default transaction isolation level for ASE is 1 (read committed), however the default behaviour of WebSphere is to use isolation level 2 (repeatable read). This has the effect that even rows that are read will be kept locked until the transaction has finished. In turn, this can lead to a high change of sessions blocking each other or the need to raise to ASE configuration parameter "number of locks" to a very high number (more than 1 million is not uncommon). To resolve this the WebSphere developers need to override the isolation level.

Note: to see what isolation level a running spid is using do this:

dbcc traceon(3604)
go
dbcc pss(0,<spid>)
go

Look in the output for value after "pisolation" (somewhere halfway in the output).