[jboss-user] [EJB 3.0] - Re: SLSB basic design question
Always pass values as method parameters - do not use fields. With an SLSB multiple threads can be using it simultaneously and if you use a field you will get interesting results. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4171094#4171094 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4171094 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [EJB 3.0] - Re: SLSB basic design question
PeterJ wrote : With an SLSB multiple threads can be using it simultaneously Huh??? What about SLSB pools then? I was sure that a thread takes SLSB instance from the POOL, executes it and returns it back for later use. Never two threads execute on the same SLSB instance. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4171099#4171099 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4171099 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [EJB 3.0] - Re: SLSB basic design question
Peter is right, though for the wrong reason. :) SLSBs *do* have state, as the instance is returned to the Pool after use. Therefore invocation-specific data should not be kept in instance members of a SLSB. For SFSB this is acceptable (and good practice) because it's guaranteed that every subsequent invocation upon a given proxy will invoke upon the same SFSB instance. However, EJBs are Thread-safe - no two invocations will use the same instance concurrently (by spec anyway): EJB 3.0 Core Specification 4.7.11 wrote : The container must ensure that only one thread can be executing an instance at any time. S, ALR View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4171100#4171100 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4171100 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [EJB 3.0] - Re: SLSB basic design question
ALRubinger wrote : SLSBs *do* have state, as the instance is returned to the Pool after use. Therefore invocation-specific data should not be kept in instance members of a SLSB. Thanks, Andrew. This makes good sense. However, if I only run one single facade method, and previous old state doesn't bug me (all variables are re-initialized before used), can such temporal use of fields be justified? Imagine I have a chain of methods inside a SLSB. a calls b, b calls c, c calls d, etc. Facade method receives a parameter. I need to use that parameter down the chain of execution. Should I put that parameter in each method declaration? Ouch ... Doesn't look very appealing, don't you think? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4171104#4171104 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4171104 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [EJB 3.0] - Re: SLSB basic design question
vanyatka wrote : ...if I only run one single facade method, and previous old state doesn't bug me (all variables are re-initialized before used), can such temporal use of fields be justified? Sure, but you've set up a maintenance gotcha that is pretty easy to violate and will be difficult to debug. Also, you'll be less likely to see the inconsistencies exhibited in development, meaning it's likely that Peter's weird stuff will happen in Production. So as a general rule, I'd avoid this paradigm unless you can say: 1) There's no cleaner way 2) Document the hell out of it to make sure the instance var is cleansed upon each invocation vanyatka wrote : Imagine I have a chain of methods inside a SLSB. | a calls b, b calls c, c calls d, etc. | | Facade method receives a parameter. I need to use that parameter down the chain of execution. Should I put that parameter in each method declaration? Ouch ... Doesn't look very appealing, don't you think No, cluttered APIs are not pretty, though this approach *is* pretty foolproof. You can also look into: 1) Store that parameter in a ThreadLocal 2) Each method looks to the ThreadLocal for the value 3) Apply an interceptor to, after invocation, clear the value of the ThreadLocal (as the Thread will also be returned to a pool). S, ALR View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4171109#4171109 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4171109 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [EJB 3.0] - Re: SLSB basic design question
Thanks for sharing your insights on this issue! ALRubinger wrote : Sure, but you've set up a maintenance gotcha that is pretty easy to violate and will be difficult to debug. Also, you'll be less likely to see the inconsistencies exhibited in development, meaning it's likely that Peter's weird stuff will happen in Production. So as a general rule, I'd avoid this paradigm Agreed. I don't like it either. That's why I brought it up ) anonymous wrote : | unless you can say: | 1) There's no cleaner way | Before asking this question I thought of two, you introduced the third, and now I don't like any of them ) anonymous wrote : | 2) Document the hell out of it to make sure the instance var is cleansed upon each invocation | Good point. anonymous wrote : | No, cluttered APIs are not pretty, though this approach *is* pretty foolproof. | Ugly or fragile? That is the question. anonymous wrote : | You can also look into: | 1) Store that parameter in a ThreadLocal | 2) Each method looks to the ThreadLocal for the value | 3) Apply an interceptor to, after invocation, clear the value of the ThreadLocal (as the Thread will also be returned to a pool). | Looks kinda the same as our discussed approach, only you have to clean a single variable. To make sure that variables are clean I can devote a special init() method for that, and call it each time inside my business methods. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4171114#4171114 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4171114 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [EJB 3.0] - Re: SLSB basic design question
Of course an alternate approach is to go back to what was done with EJB 2.x to
support unittestability - place all of the methods into another object, and
make the SLSB a mere facade for that object. Then each SLSB method would look
like:
void doSomething(int var) {
new RealObject(var).doSomething()
}
Unfortunately, this approach generates unneeded garbage.
Personally, I vote for passing the values along from method to method. Less
chance of unintentional bugs later on.
And besides, by adding fields (whose values change) to an SLSB you are in
effect adding state to what should be a stateless object. And as Andrew pointed
out, you will be bit by this during maintenance (most likely several
months/years down the line when someone inadvertently assumes that the field
actually hold real state, and not pseudo-state).
And besides, IDEs are pretty good about helping you manage method signatures.
For example, say you wanted to add a second parameter to your facade method,
and you dutifully add the parameter to the call_internal method invocation -
Eclipse will flag the method call and provide suggested changes, including
adding the parameter to the call_internal method.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4171134#4171134
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4171134
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
