We're still in the initial implementation phase, so we haven't made a firm 
decision on the server container. In development I've been using the 
jetty-maven-plugin to run the server locally, so it probably makes sense to use 
Jetty in production as well.  I will try implementing the filter today and get 
back to you about it.

Thanks,
Adam

________________________________________
From: Aristedes Maniatis <a...@maniatis.org>
Sent: Friday, April 8, 2016 2:40 AM
To: user@cayenne.apache.org
Subject: Re: ROP: detecting that my client connection has timed out

What container are you using on the server? For us, we use Jetty and it is 
simple enough to track sessions there (and store additional data against the 
session such as the database User object). Then use 
https://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpSessionListener.html
 to do something server-side in reaction to a session timeout.

Also look at javax.servlet.Filter. Implement:

        public void doFilter(ServletRequest servletRequest, ServletResponse 
servletResponse, FilterChain chain) throws IOException, ServletException {

and you should be able to add something like:

                try {
                        chain.doFilter(request, response);
                } catch 
(org.apache.cayenne.remote.service.MissingSessionException ex) {
                        // session forged or expired or user kicked out
                        session.invalidate();
                        response.sendError(HttpServletResponse.SC_UNAUTHORIZED);
                }

You should be able to catch the 401 error on the client end and do something 
useful with it.


Does that help?

Ari


On 8/04/2016 3:06pm, Adam Boyle wrote:
> 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 <a...@maniatis.org>
> Sent: Friday, April 8, 2016 12:30 AM
> To: user@cayenne.apache.org
> 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
>

--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

Reply via email to