|
| Re: [CDO] CDOLock: handling of network outages [message #1741984 is a reply to message #1739728] |
Fri, 12 August 2016 10:29  |
|
Am 04.08.2016 um 13:13 schrieb Robert Schulk:
> Hi all,
>
> let's consider the following situation:
> * user is connected to a CDORepository
> * user acquires a CDOLock on a resources
> * the network gets disconnected
>
> In this case, the resource lock is maintained - probably the server waits until the client might reconnect?
>
> I think that this is a great feature,
This is not a feature, but rather a highly OS-dependent side-effect. Let me explain: The lifespan of a CDOLock is
restricted by the lifespan of the locking CDOView (the "lock owner"). The lifespan of the CDOView is restricted by the
underlying CDOSession which, in turn, is restricted by its CDOSessionProtocol. The latter is restricted by its IChannel
and that is restricted by its IConnector, which represents the physical transport connection (likely TCP in your case).
In case of physical network outages it highly depends on the OS and the connection configuration whether (and what)
timeouts apply (likely 15 minutes in your case).
> but we run into the following issue: * user closes the client application so that it will never reconnect to the server
> * network reconnects
> * user opens another instance of the client application and would like to access the same resource - but it will stay
> locked
> * After some time, the lock seems to be automatically released (I think it was around 15min)
Yes, that all seems in line with what I explained above.
To work around the uncertainty of the external timeouts I strongly recommend to route an
org.eclipse.net4j.signal.heartbeat.HeartBeatProtocol through the IConnector that's used by the CDOSession. It would
cause the client-side and the server-side sessions to time out predictably. The subclasses of
org.eclipse.emf.cdo.internal.net4j.RecoveringCDOSessionImpl (e.g., FailoverCDOSessionImpl and
ReconnectingCDOSessionImpl) use the same approach.
>
> So is it possible to:
> 1) identify if a lock comes from a non-responsive client?
You could implement your own JMS-like protocol via CDORemoteSessionMessages, or just rely on smaller timeouts with a
HeartBeatProtocol .
> 2) obtain the IP address of a client that is holding a lock?
You could either use CDORemoteSessionMessages or determine the IConnector's IP address. For the latter approach look at
the CDOLockOwners of the CDOLockState. The CDOLockOwner gives you the session ID, which you can use to obtain the
ISession, the ISessionProtocol, the IChannel, and the IConnector.
> 3) modify the timeout until the session of a non-reachable client will be automatically disconnected?
Yes, with a HeartBeatProtocol.
> 4) remotely disconnect the user or the lock?
You can write server-side code that closes the IView that owns the lock. To deal with physical network outages you need
a HeartBeatProtocol.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.02615 seconds
] 
Search
Help
Register
Login
Home
