Re: session lock table growth out of control

josh:

the table tblsessionrellocks contains a list of released locks for any=
 given iis session.  basically, this list is used to compute smaller=
 checkout lists to transmit to the client on a refresh command.

because the server is tied to iis' session handling, a restart of vault=
 server (iis) will completely empty the table.  due to the delicate nature=
 of trying to tie iis to the sql database, we've made a list of two or=
 three more things we're going to try to place in the server to make it=
 more robust in handling abandoned sessions.


now, lets talk about what we can see in your current setup (vault 2.0.x) - 

1) of the hundreds of thousands of rows you mention, was this table ever=
 empty?  is it empty after a restart of vault server (iis)?
2)  can you check your server's log (%temp%\sgvault\sgvault.log)?  look for=
 any information related to sessions, deadlocks or connection timeouts.=
  any entries?
3)  there is the potential for abandoned sessions if the sqlcommandtimeout=
 in vault.config is set too low.  what is your current setting?  you could=
 add another order of magnitude to this value, and restart vault server=
 (iis).
4)  the cleanup of sessions is related to session timeouts within iis.=
  what is the current setting in vault server's web.config for the=
 sessionstate's timeout attribute?  you could try setting this to a lower=
 value in order to reduce the amount of time an abandoned session is left=
 in the database.

i'll await your response.

thanks, 
jeff clausius
sourcegear

*********** REPLY SEPARATOR  ***********

On 4/20/2004 at 9:30 PM Josh Kewley wrote:

>Hello,
>
>With only a handful of developers working on our Vault server, we are
>running into a problem where hundreds of thousands of rows in the session
>lock table (tblsessionrellocks) are being created upon check-in that are
>not being deleted. This causes the size of our database to grow by
>gigabytes each week, and causes Vault to operate very, very slowly. I have
>seen mention of this problem with past versions of Vault, but apparently
>it was something that was fixed in recent versions.
>(http://support.sourcegear.com/viewtopic.php?t=3D285). Our hack to keep
>productive in the meantime has been to delete all records from this table
>when vault is not being used. 
>
>We started with the 1.x version, and have been following the upgrade paths
>(without incident) to the current version that we run (2.0.2). We are
>running both our SQL server and web server on Windows Server 2003. We
>notice the same problem with the vault client, as well as with the VS.Net
>IDE. We do a lot of massive check-ins after generating base libraries,
>which is when the server really gets beat up.
>
>Assistance is appreciated.
>-Josh
>
>_______________________________________________
>vault-list mailing list
>[email protected]
>http://lists.sourcegear.com/cgi-bin/mailman/listinfo/vault-list