Thanks for the response. I could be overlooking it, but I don't see an answer to my central question: how can I detect that the client has timed out? The nature of our application prevents us from using a keep-alive type solution; it is meant to be used in highly regulated environments (which is one of the reasons I chose Cayenne ROP: it provides a way to hide the database details from the users). Even if I could use an auto-reconnect solution, I would still need to be able to detect that the connection has timed out, and I have failed to find a way to actually detect that.
I suppose that another (less-hacky) way I could approach this would be to logically detect a "timeout" by keeping the actual connection alive and storing login session info in the database and updating it with the current date time every time a Cayenne action is performed. This code would check for a timeout beforehand and prompt the user to re-authenticate before performing said action. The main problem there is maintainability; I'd have to add this check to every place I intend to submit any sort of Cayenne action unless there is a way to hook this sort of check into the ObjectContext. Does anyone know of a better way? Perhaps some advice for this novice enterprise developer? Thanks again, Adam ________________________________________ From: Aristedes Maniatis <[email protected]> Sent: Friday, April 8, 2016 12:30 AM To: [email protected] Subject: Re: ROP: detecting that my client connection has timed out On 8/04/2016 1:28pm, Adam Boyle wrote: > Is there a simple way of detecting that the connection is dead so that I can > prompt the user to reconnect? I don't think you need to prompt the user if you keep the user's authentication details in memory. Just create a new session with them. > On a related note, what happens to the existing client ObjectContext objects > that are in use if the connection is able to be re-established? Are the > uncommitted PersistentObjects previously created in those contexts lost > forever? Those contexts are no longer associated with a session on the server (once your session times out). So you either have to recognise that a user is connecting again after a connection error and give them a handle on the same session id they had last time, or else start a new session and lose the old contexts. The problem is: can you be sure the state of those contexts still make sense? > The only (hacky) solution I can think of is to actually run a keep-alive > thread to periodically send a low-latency query to Cayenne to keep the ROP > session active and separately track application activity and prompt the user > to enter their password if a certain period of time has passed with no > activity. The problem that I see with an approach like that is that there are > lots of ways that activity could be missed, the application is not truly > timing out, and it really doesn't address the underlying problem which is > that sessions need to time out for a reason and there doesn't seem to be a > way to detect such a timeout. Well this is outside Cayenne itself, but part of the reason we recently did the work in trunk (CAY-2065) to untangle Cayenne from Hessian and from the HTTP layer. Then you can manage the session more easily yourself to do whatever you want. For example, we have a ping every minute from the client that: * keeps the session alive (we don't want the session to die just because the user went to have lunch) * allows us the keep the server-side session timeout quite low (good to expire sessions for users who dropped off the network without a proper logout) * allows the server to track which users are having network issues In the last six months we've been doing a bunch of work with ActiveMQ/STOMP which might eventually replace that ping. That way we have two way server-client communication and the server can quickly see which clients have lost network connection without a ping. Nice to see a fellow Cayenne ROP user. There aren't many of us and it is really a very powerful bit of functionality. Ari -- --------------------------> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
