Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 10 of 11 total |
disconnected sessions and record locks |
Thu, Jan 26 2006 7:06 PM | Permanent Link |
Jaweed Saleem | Hi,
We are using DBISAM v3.21 and Delphi5 under a c/s environment. Recently we had a user ctrl+alt+del out of the application while editing a record. But when she goes back into the application she can't edit that record anymore because it says that it's locked by another user. Now I take it that once a session is disconnected, when a user logs back into the system it will re-use that disconnected session (as long as it hasn't expired) because this will allow faster reconnection? Like connection pooling but per user? If that's the case then it makes sense from an efficiency point of view but is there a way to handle this lock (i.e. reset it somehow after detecting that it came from a disconnected session)? Thanks in advance |
Thu, Jan 26 2006 7:34 PM | Permanent Link |
"Ralf Mimoun" | Jaweed Saleem wrote:
> Hi, > > We are using DBISAM v3.21 and Delphi5 under a c/s environment. > Recently we had a user ctrl+alt+del out of the application while > editing a record. But when she goes back into the application she > can't edit that record anymore because it says that it's locked by > another user. The connection will time out after a while, depends on configuration. > Now I take it that once a session is disconnected, when a user logs > back into the system it will re-use that disconnected session (as > long as it hasn't expired) because this will allow faster > reconnection? Like connection pooling but per user? How should it? What if a user is using two instances of one application? You would be in big trouble if they'd use the identical connection. What if you have multiple users using a router with NAT to connect to the db server? The server does not know if the client is really down or just did not need data since some minutes. So, the IP connection itself is closed, but the server will wait some time for exactly that client for reconenction. And because there is no way the server can ask the client if he is alive, the client should do that. Add a "ping" (eg., pull the server date+time) every 10 seconds, and set the timeout to eg. 30 seconds, and you should be safe. Version 4 has a built in ping just for that. Ralf |
Thu, Jan 26 2006 8:22 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Jaweed,
<< If that's the case then it makes sense from an efficiency point of view but is there a way to handle this lock (i.e. reset it somehow after detecting that it came from a disconnected session)? >> In such a case, you should remove the session manually. That will remove the record lock and allow the user to edit the record again. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Jan 27 2006 1:11 AM | Permanent Link |
Jaweed Saleem | Ralf Mimoun wrote:
> Jaweed Saleem wrote: > >>Hi, >> >>We are using DBISAM v3.21 and Delphi5 under a c/s environment. >>Recently we had a user ctrl+alt+del out of the application while >>editing a record. But when she goes back into the application she >>can't edit that record anymore because it says that it's locked by >>another user. > > > The connection will time out after a while, depends on configuration. > > >>Now I take it that once a session is disconnected, when a user logs >>back into the system it will re-use that disconnected session (as >>long as it hasn't expired) because this will allow faster >>reconnection? Like connection pooling but per user? > > > How should it? What if a user is using two instances of one application? You > would be in big trouble if they'd use the identical connection. What if you > have multiple users using a router with NAT to connect to the db server? > > The server does not know if the client is really down or just did not need > data since some minutes. So, the IP connection itself is closed, but the > server will wait some time for exactly that client for reconenction. > > And because there is no way the server can ask the client if he is alive, > the client should do that. Add a "ping" (eg., pull the server date+time) > every 10 seconds, and set the timeout to eg. 30 seconds, and you should be > safe. Version 4 has a built in ping just for that. > > Ralf > > So, let me get this straight. If a session is disconnected and that client reconnects, then the disconnected session is not re-used. That's ok then but why does it complain about the record being edited by another user? In this case why isn't the record lock being reset when the session is disconnected? or alternatively (if i misunderstood you) and the disconnected session is being reused by exactly that client, then why doesn't it detect that the last record lock was by that client and reset itself when they re-connect? |
Fri, Jan 27 2006 1:13 AM | Permanent Link |
Jaweed Saleem | Tim Young [Elevate Software] wrote:
> Jaweed, > > << If that's the case then it makes sense from an efficiency point of view > but is there a way to handle this lock (i.e. reset it somehow after > detecting that it came from a disconnected session)? >> > > In such a case, you should remove the session manually. That will remove > the record lock and allow the user to edit the record again. > Hi Tim, This would cause some big administrative/support issues. Is there a more elegant way (through code) to detect that the lock was being held by the current user and releasing it? |
Fri, Jan 27 2006 3:57 AM | Permanent Link |
"Jose Eduardo Helminsky" | Jaweed
It's not what you want but if you set "Max Dead Sessions" to 0 and check dead sessions every 15 seconds, the record will be unlocked at last in 15 seconds. Eduardo |
Fri, Jan 27 2006 7:52 AM | Permanent Link |
"Ralf Mimoun" | Jaweed Saleem wrote:
.... > So, let me get this straight. If a session is disconnected and that > client reconnects, then the disconnected session is not re-used. If exactly the same client reconnects (the one that did the login, not another instance of the same EXE), the connection will be reestablished/reused. .... > or alternatively (if i misunderstood you) and the disconnected session > is being reused by exactly that client, then why doesn't it detect > that the last record lock was by that client and reset itself when > they re-connect? It was not the same client application. Ralf |
Fri, Jan 27 2006 7:53 AM | Permanent Link |
"Ralf Mimoun" | Jose Eduardo Helminsky wrote:
> Jaweed > > It's not what you want but if you set "Max Dead Sessions" to 0 and > check dead sessions every 15 seconds, the record will be unlocked at > last in 15 seconds. And if there is no automatic ping, the lock will also be thrown away if the user need more than 15 seconds to edit the record Ralf |
Fri, Jan 27 2006 9:32 PM | Permanent Link |
Jaweed Saleem | Ralf Mimoun wrote:
> Jose Eduardo Helminsky wrote: > >>Jaweed >> >>It's not what you want but if you set "Max Dead Sessions" to 0 and >>check dead sessions every 15 seconds, the record will be unlocked at >>last in 15 seconds. > > > And if there is no automatic ping, the lock will also be thrown away if the > user need more than 15 seconds to edit the record > > Ralf > > hmmm.... This would be inconvenient. What about setting the dead session expiry times down to 15 seconds. Would this clean the disconnected sessions without affecting current connections? what would be the downsides of doing this? Sorry about being a thicky on this guys. I can't believe that nobody else seems to have this kind of problem under client/server (at least ones who don't want to dedicate large chunks of time for the support issue of manually clearing disconnected sessions with locks). Thanks for your responses. |
Fri, Jan 27 2006 9:34 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Jaweed,
<< This would cause some big administrative/support issues. Is there a more elegant way (through code) to detect that the lock was being held by the current user and releasing it? >> The only way to deal with this in a seamless way is to use Optimistic locking instead of Pessmistic locking (TDBISAMSession.LockProtocol property). That will ensure that record locks are not held across server calls. -- Tim Young Elevate Software www.elevatesoft.com |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Tuesday, September 17, 2024 at 04:19 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |