Re: JavaClient session timeout?
Re: JavaClient session timeout?
- Subject: Re: JavaClient session timeout?
- From: David Avendasora <email@hidden>
- Date: Mon, 30 Mar 2009 13:18:19 -0400
On Mar 30, 2009, at 11:16 AM, Stamenkovic Florijan wrote:
On Mar 30, 2009, at 10:24, David Avendasora wrote:
Yes, there is. By default I believe it is 30 minutes, or maybe 20.
I'm not entirely sure. It is the same session timeout that a web
client session has by default
It's the same session mechanism, controlled with the same server
side properties etc...
In D2JC I get a nice, "Your Session has Timedout on the server. The
application will quit now." dialog box the next time the client
tries connecting to the server.
Yeah, you also get that in non-direct development. Though I believe
there are ways one can do something JC does not expect, and end up
with an exception instead of this message. Have not experimented
much with it though.
Hmm. I haven't ever gotten anything with D2JC except that dialog. I
also get it if the server has become unreachable.
Note, that depending on how much data is cached on the client, you
could be working for quite a while on the client without ever
talking to the server because if it doesn't have an explicit reason
to talk to the server, it doesn't. The default is plenty of time if
someone is actively using the client application, but being a
desktop application most users will expect to be able to leave it
running for hours at a time without actually using it. You need to
balance this expectation with data-freshness and such and come up
with an appropriate timeout for you particular situation.
Also, users simply need to know that the data they are accessing is
not stored locally. Session timeouts are one of the aspects of this.
But, I agree, ideally we want to make it as convenient for the user
as possible.
With that said, I think it would be much better to have a more pro-
active approach to session timeouts. Some type of notification to
the user that their session is going to timeout if they have
unsaved changes, and an option to automatically reconnect without a
relaunch would be very helpful too. I have not implemented these
things, but I don't really see a reason why they couldn't be.
Flor probably has some ideas on how to do this as he more directly
manages the client-server connection since he doesn't use WebStart.
The problem is that the server can't just "inform" the client of
anything, as client-server communication is request-response based.
It *might* be possible for the client to time the period elapsed
since the last request, and notify the user based on that. However,
this might be tricky. Or it might not... I am not sure, never tried
that.
This is the approach I was thinking of. Have the client keep track of
how long since the last server communication (I have no idea how to do
that...) and set a timer based on the session timeout value. It's only
job would be to give the user a few minutes warning to finish what
they were working on, extend the session (if possible, a ping as you
describe below would be perfect) or quit.
Right now this isn't a huge issue as most users are used to the
concept of a Web session timing out without warning so they seem to be
able to grasp that a desktop application can do the same. Some
websites warn you they are about to timeout, but not all.
Another approach I considered at some point is to have the client
"ping" the session at small intervals. Now, this should be fairly
easy to do, and should ensure that the session never expires. There
are some potential problems with this:
- multithreading: the "ping" of course will get scheduled on
another thread, which EOF might not like. One could schedule it to
happen on the EDT, but that might result in an occasional glitch in
the GUI. Or, maybe if using a stateless RMI method for the purpose
of the ping, this would not be a problem
- session accumulation on the server: not sure what the
implications of this could be.
The biggest draw-back I see here is the longer the session hangs
around, the more stale the data is getting. In short, you are making
things easier for the user, at the expense of a lot of time and care
making sure that your client-side application has fresh data. It could
be worth it, but maybe not.
In short, I think it all depends on your needs.
I agree 100%. There should be some properties-based setting that will
still set the maximum session life.
I'd be happy to implement the "ping" system, and put it into
WOJCKit, if somebody else has the time to test it. I am waaaay too
busy at the moment to deal with that. Anyone interested?
I'd be happy to test it if there's some way to use it with D2JC,
otherwise, I'll test when I start my JBND project. Should be soon!
Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden