> 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.
Right... ahem, not so much :) The issues we have with this approach are:
a) security - you can tweak the client and force it to send different ID, impersonating someone. Having that in server in SFSB you can send whatever ID you want it will still use the one you were assigned after login.
b) would you give me an example how does EJB automatically filter results based on dynamically applied filters and rules based on user ID? (that is more sarcastic, rhetorical question just in case you were wondering...). I mean lets say we have a list of contacts. User ID 1 can see all, user ID 2 can see only those that have "Support" tag etc. Everything is dynamic, stored in database, unknown at design time. Now, if you show me how EJB will do that automatically, I will be grateful and will be keen to apologize for being sarcastic.
>
> 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).
Sorry, I still do believe yes, you do. Or, rather, I do. For exactly those reasons I described.
Thanks anyway,
dale
>
>
> 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=2398
> 91
> >
> >
> ------------------------------------------------------
> ---------------
> > To unsubscribe, e-mail:
> users-unsubscribe_at_glassfish.dev.java.net
> > For additional commands, e-mail:
> users-help_at_glassfish.dev.java.net
> >
> >
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail:
> users-help_at_glassfish.dev.java.net
[Message sent by forum member 'dalecooper82' (dalecooper82)]
http://forums.java.net/jive/thread.jspa?messageID=240996