For me it looks like an insane idea to use SFSB for Swing application
just because you do not want to send user ID on every call, because
you really do not have to send user Id and his/her credentials as this
is what EJB controls automatically.
There is no reason to use SFSB, excluding really _few_situations, for
example - where you have to keep something between calls that is
either not serializable or too large to transfer back and forth (good
example might be when you do a query with max result limit, so in next
call you can get next part, then next again and destroy SFSB when user
does not want to see more results or when there is nothing left).
Regards,
-Witold Szczerba
2007/10/12, glassfish_at_javadesktop.org <glassfish_at_javadesktop.org>:
> Hi,
>
> this is more generic JEE (portable) question however Glassfish is my server and the community always seemed friendly and responsive, so here I go with very stupid question.
>
> I am working on an app that has rich (Swing) client, therefore unlike in web app there are quite a few threads running simultaneously.
>
> We are using one stateful session bean as facade for a client to do anything on server. The client uses singleton that holds ref to remote interface.
>
> The reasons for that are just one JNDI lookup at app start (client runs as stand alone client, not in client app container) and more importantly storing session values on the server, mostly user id and rights, allowing to filter queries on server side only, without transferring the same (current user related) data back and forth every time
>
> Naturally we are now facing ConcurrentAccessException :(
>
> My questions are:
> a) is that bad design from the very beginning?
> b) how do you get around this situation?
> c) one solution would be to avoid session bean and transfer user id with every call to (stateless) session bean, however this has disadvantage that app proprietary user rights and filters would need to be reconstructed with every call and that would certainly result in performance
> d) other solution is to check for concurrent exception and possibly wait and try again. is that the way to go?
>
>
> Thanks in advance for any comments,
> Dale
>
> P.S. And congrats to glassfish team for v2 FCS, well done!
> [Message sent by forum member 'dalecooper82' (dalecooper82)]
>
> http://forums.java.net/jive/thread.jspa?messageID=239891
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>