Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 11 total
Thread disconnected sessions and record locks
Thu, Jan 26 2006 7:06 PMPermanent 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 PMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent 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 AMPermanent 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 AMPermanent 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 AMPermanent 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 AMPermanent 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 Smile

Ralf

Fri, Jan 27 2006 9:32 PMPermanent 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 Smile
>
> 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 2Next Page »
Jump to Page:  1 2
Image