Nick,
Ejipt 1.0.2 supports login sessions based on threads, thread groups or the
VM (i.e. the client process). You set the "session scope" with the
'ejipt.sessionScope' key in the system properties before any connections are
made. Valid values are: 'thread', 'thread_group' or 'vm'.
Ejipt 1.1 (just released) adds an additional UserSession class that operates
similarly to javax.transaction.UserTransaction and provides on-the-fly
association of login sessions with threads. Sample1d illustrates using
UserSession.
Imre Kifor
Valto Systems
>Hi,
>
>I am using the Ejipt EJB server. Access to all resource management
>facilities rely on the currently executing thread.
>If you have a situation where your client logs in and is logged in on
>the servers User Manager using the clients 'main' thread.
>Then your client launches a Gui which accepts user actions triggering
>remote methods on EJBs, then the requests originate from the clients
>event-dispatching thread. The EJB server doesn't recognise these to come
>from the same client that originally logged in.
>
>An obvious workaround is to ensure all requests orginate from the same
>thread on the client - e.g. A dedicated proxy thread or the
>event-dispatching thread itself using Swing's 'invokeAndWait' method.
>
>However, I just wondered if I'm missing something and if there's a
>smarter way of doing this on the server ?
>
>Thanks,
>
>Nick.
>
>===========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff EJB-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
