users@ejb-spec.java.net

[ejb-spec users] Re: EJB_SPEC-25: passing session bean references around

From: Carlo de Wolf <cdewolf_at_redhat.com>
Date: Mon, 10 Oct 2011 12:20:22 +0200

Hi Jon,

I can't find any constraints in the spec that doesn't allow references
to be passed around.
Maybe I missed them. Could you point them out please?

Thanks,

Carlo

On 10/10/2011 04:38 AM, exabrial_at_gmail.com wrote:
> Hello everyone!
>
> I've created two new feature requests for EJB3.2:
> http://java.net/jira/browse/EJB_SPEC-24
> http://java.net/jira/browse/EJB_SPEC-25
>
> I feel like @Stateful EJBs are a forgotten and hated love child of the
> JEE world. I think they have a lot of potential to solve and simplify
> our lives. I've created two JIRA issues that would greatly enhance
> their potential usefulness.
>
> First, I'd like to see concurrency on Stateful EJBs. I think recycling
> the existing @Lock(READ) and @Lock(WRITE) annotations would be a simple
> solution. I feel like I keep writing a lot of synchronization code in
> my webapps, and this would allow for a real simple way to store
> concurrent user data without a lot of drama.
>
> The second is I'd like to be able to pass Stateful EJBs around like
> POJOs. I think a very neat scenario would be to pass a stateful EJB
> like a hot potato between several stateless EJBs. Imagine the typical
> shopping cart example. After a user finishes their order, the result
> has to go to a "shipping queue."
>
> Wouldn't it be neat to place the Stateful EJB on an MDB queue? The
> container could easily passivate the EJB until the MDB got around to
> shipping the order.
>
>
> My main motivation for creating these two requests is to solve some
> problems in Domain Driven Design. DDD was created to reduce network
> communication from SOA. SOA was created to centralize business logic.
> These are normally competing goals, since your implementation doesn't
> follow your state.
>
> These two requests would make Stateful EJBs a cornerstone in DDD. You
> would have both centralized business logic, but still have the ability
> for state to be passed around easily.
>
> Thank you everyone for your consideration, I look forward to comment
> and discussion.