Hi,
We are also working on DDD on real and big projects in my company.
We use Stateful EJBs as well as the backbone.
Stateful EJBs are very convenient and especially for DDD.
They have been banish in the past because of lots of good and bad reasons.
Nowadays, thanks to containers enhancements, Stateful management has been
greatly enhance and they are fully usable.
When using JPA, they are absolutely required to get EPC and use them.
Regarding the synchronization, I fully agree with you.
The restriction has no real reason to remain.
So +1 for concurrent accesses.
Would like to get Adam's opinion because I guess he has a great experience
implementing DDD in Java EE.
Regarding the second point, I've no real opinion except that AFAICR,
passivation is not mandatory.
I don't either see the benefit. May be, you can elaborate a bit more on a
new thread so that, it's easier to follow.
Jean-Louis
2011/10/10 <exabrial_at_gmail.com>
> 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.
>