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.
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.
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.
In short, I think it all depends on your needs.
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?
F
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
