Doorgaan naar hoofdcontent

Stateless session beans - an oxymoron

So I had a discussion about stateless session beans and them containing state.
Coming from spring, I expected stateless to mean no state what so ever. This is because the default scope for beans in spring is Singleton. This allows beans to be shared (and wired) on application startup, ensuring that no real bean pool management is necessary. The container decides to use separate beans for injection, or all the same, since there is no real 'pool' to speak of.

Compare this to EJB, which has a stateless session bean. This compares with a stateful session bean.
A stateful session bean contains the state through the entire session. A stateless session bean does not.
However, a stateless session bean can contain state. Stateless session beans are request scoped, meaning that any state they have they can access within the request.

This, of course, comes from EJB's Stateful and Stateless EJB's of old, where it was made that way.
Spring made sure that stateless = no state, under no circumstance. Hence, my confusion.

Live and learn in EJB-land!...

Addendum
What still remains, of course, is that beans are recycled between requests. So if you add data to a stateless session bean, it should be invalated/cleared after use.

Usually, when a stateless EJB contains state, it a database connection, or something like that. (although we can inject that these days). Having temporary state in there can screw up the working of your EJB when that state is used in another session after the bean is recycled...

So, 'still' keep your stateless session bean as stateless as possible...

Labels

Labels:

Reacties

Een reactie posten

Populaire posts van deze blog

Spring's conditional annotation with properties

Spring has a nice @Conditional annotation, to have the option to have beans be available in the context depending a specific condition (Of course, this can also be realized by using @Configuration objects, but that's a different post). Ideally, we'd have the option to have a condition evaluate to true or false depending on a property. Sadly, Spring does not support that out of the box. Googling and looking around gives a partial solution, but the complete one here, so we won't forget: /** * Components annotated with ConditionalOnProperty will be registered in the spring context depending on the value of a * property defined in the propertiesBeanName properties Bean. */ @Target({ ElementType.TYPE, ElementType.METHOD }) @Retention(RetentionPolicy.RUNTIME) @Conditional(OnPropertyCondition.class) public @interface ConditionalOnProperty { /** * The name of the property. If not found, it will evaluate to false. */ String value(); /** * if the p...
Een reactie posten
Meer lezen

OSGI insights without sonar

So I was on a project without sonar. Oh my. Well, it was an OSGI project, so the problems couldn't be that bad, right? But how good were they (and what things were bad?) I found Stan4j , a code analysis tool for eclipse, which draws nice graphs and can handle osgi pretty well it seems. Now I can see that dependencies/bundle names aren't properly aligned (even though OSGI doesn't complain), etc.
Een reactie posten
Meer lezen

JPA and transactions

So I was working with JPA and transactions. Consider the following: In bean 1, with implicit TX 1, managed entities are loaded/created,and returned in bean 2, with implicit TX 2, entities are modified in bean 3, with NO TX, bean 1 is called, and the results are passed to bean 2. and bean 4 is similar to bean 3, but with it's own transaction, TX3 What happens when bean 3 finishes: are the entities updated? What happens when bean 4 finishes, are the entities updated? The answer to this is simple; entities are managed through a persistance context. That context is tied to the transaction. So in bean 2, there is a difference. When called from bean 3, it runs in a different transaction then bean 1, and thus a different persistance context, and thus the entities are not managed 'by this transaction'.When called from bean 4, it all runs in the same transaction, TX3, and the results are persisted.
Een reactie posten
Meer lezen