We are trying to implement a GWT security solution that will allow us to scale our solution by addition additional servers. We would like to do this without the need to cluster them or have a load balancing solution that provides server affinity for the lifetime of the user's session.
To do this we would need to create a virtual session identifier that would be passed on each of the GWT-RPC calls as a cookie, url parameter, or rpc parameter. We would like the individual GWT-RPC calls to be able to do the following: 1) Determine if the session is valid and if not throw appropriate not authenticated exception. 2) Use J2EE session to cache virtual session information (user, roles, etc.), and other context data relating to current RPC calls. RPCs will treat the J2EE session as a read/write through cache. If data for current call is not in the J2EE session it will be loaded and cached. Is this a practical solution? Is anyone out there doing something like this? I cannot find any practical examples of how this might be done. I have seen excerpts where people talk about returning a session token but those examples end up using the J2EE session Id. Using the J2EE session Id would require either server affinity or server clustering make sure that J2EE session is always used. This solution does not scale horizontally they way I'm talking about here. I could really use some help here. Thanks, Dawson --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
