So would one say that the declarative transaction handling is a good reason to
use a SessionBean over a POJO during an event scoped process?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4045380#4045380
Reply to the post :
Btw, what's the point of having an event scoped SFSB? SFSB's strength is
statefulness across requests, which is why they default to conversational scope.
Just curious.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4044979#4044979
Reply to the post :
So that during the processing of the event (request) the SessionBean maintains
its state across method calls made to it.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4044993#4044993
Reply to the post :
You'd get the same behavior by just using a pojo. They're event-scoped by
default for that reason. Using a SFSB that way certainly works, but if you
look at the interceptor stack, there's definitly more overhead when using a
SFSB as a pojo.
View the original post :
True, but...
However, they [POJOs] do not provide the functionality of a session bean
(declarative transaction demarcation, declarative security, efficient clustered
state replication, EJB 3.0 persistence, timeout methods, etc).
(taken from 3.2.4 of the Seam doc)
View the original post :
sradford wrote : True, but...
|
| However, they [POJOs] do not provide the functionality of a session bean
(declarative transaction demarcation, declarative security, efficient clustered
state replication, EJB 3.0 persistence, timeout methods, etc).
|
| (taken from 3.2.4 of the Seam
