• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Stateless or statefull session bean

 
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,

I have a JSF application that access a stateless session bean exposing all the business logic interface ...
Today, I receive a new requirement: log all operations requested to this bean with the user id, time and so on.
I see two ways for doing that:
1 - I pollute the session bean interface by adding the user id parameter in each method (I do not like pollution, but I can stay stateless);
2 - I use a statefull session bean that stores the user id passed at the construction (statefull only for remembering user id is perhaps overkill).

I am sure you have plenty of good advices !

Thanks,

Olivier
 
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think, your stateless bean approach will be appropriate in this situation as
You need to log the user information only
 
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Olivier Scalbert wrote:Hello,

I have a JSF application that access a stateless session bean exposing all the business logic interface ...
Today, I receive a new requirement: log all operations requested to this bean with the user id, time and so on.
I see two ways for doing that:
1 - I pollute the session bean interface by adding the user id parameter in each method (I do not like pollution, but I can stay stateless);
2 - I use a statefull session bean that stores the user id passed at the construction (statefull only for remembering user id is perhaps overkill).

I am sure you have plenty of good advices !

Thanks,

Olivier



Stateless EJB are to be avoided normally, because they can become server bound and take away a big driver for EJBs in the first place. Your stateless bean will have access to the calling principal without changing any of your method signatures - would this be enough information to use? If its not you can pass what you need, assuming you know for certain no other client applications than your own call the EJBs, since you are trusting the client to tell your EJB who it is.
 
Olivier Scalbert
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Stateless EJB are to be avoid ?
Are you sure ?

Olivier
 
Paul Sturrock
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would avoid them unless I had real need of them. The biggest benefit Session Beans give us (in my opinion) is their ability to scale easily. Its harder to scale code when it become tighly coupled to the client as SFSBs tend to become.

That's not to say I wouldn't use them, they do have their place. But if there is an alternative I wouldn't use them.
 
author
Posts: 580
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Olivier,

Paul meant to say heavy/incorrect use of *stateful* session beans can become a performance bottleneck and that is correct. Stateful session beans are by design less server-friendly than stateless beans.

In regards to your original question, you really should not be using stateful session beans for the logging/tracing use case. Consider using an interceptor that does logging with a stateless session bean. If appropriate, you can look up the principal (user) name from JAAS. Alternatively, you can use the interceptor to look into the parameters of the method being invoked.

Hope it helps,
Reza
 
Olivier Scalbert
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Reza !

Ok, statefull ! I understand better!
;-)

Interceptor approach seems interesting but I never play with it.
In a next step our application will be under the protection of OpenSSO.
As the application will have to get infos from OpenSSO (user groups / to get users right ...), I will try to write an interceptor then.

Thanks again for your help,

Olivier

 
Reza Rahman
author
Posts: 580
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Olivier,

No problems. Interceptors are pretty easy and most decent EJB 3 references should cover them. OpenSSO has good integration with JAAS, you should have no issues, especially if you are using GlassFish.

Regards,
Reza
 
Olivier Scalbert
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,

Finally, it has been decided to not use OpenSSO, as safety of this application is not an issue.
Ok, we can discuss here !!!
;-)

Login will be done via a database access with login/password ...

Should I use a stateless bean with polluted interface or statefull bean just to be able to log the loged user at each call ?

Thanks,

Olivier
 
Here. Have a potato. I grew it in my armpit. And from my other armpit, this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic