--- In jug-indonesia@yahoogroups.com, "Joshua Jackson" <[EMAIL PROTECTED]> wrote: > > Dear Members, > > It is a great honor for us because one of the committer of OpenEJB and > one the Expert Group of EJB3 has decided to join our Java community > :). So please help me welcome David Blevins and make his stay in our > community comfortable and enjoyable.
Thanks for the warm welcome everyone! I've been pretty impressed with the size and activity in this community. From the text I can read, it looks like some fun and very spirited debates happen here, which is something special. I think it will be great to get the feedback of the people here as more drafts of the EJB 3.1 specification come out. EJB 3.0 was very heavily persistence focused. EJB 3.1 so far has been very heavily focused on the session bean side of things. For the first time in years we have a new bean type, the @Singleton. In my opinion, the Singleton is going to replace a lot of what people are using @Stateless for today. The Singleton is essentially what you get if you take a Stateless bean and adjust the pool size to be exactly 1 and could allow concurrent access to that bean like a servlet. It can do everything a Stateless can do such as support Web Services, Security, Transactions, etc. It will have an @Startup annotation which is similar in concept to the servlet <load-on- startup>, but unlike servlets it doesn't take a number as an argument. Instead, you can use an @DependsOn annotation to say which other Singletons you need and the container will ensure they start before you. Singletons will also support two modes of concurrent access, Container-Managed Concurrency (the default) and Bean-Managed Concurrency. With Bean-Managed Concurrency the container sends all invocations into the bean and let's the Singleton bean instance decide how and when to synchronize access, if at all. Here the 'synchronization' keyword is allowed as well as the full javax.util.concurrent set of libraries. With Container- Managed Concurrency, the container will enforce concurrency for you. Two modes, called "locks" will exist and can be assigned to the class or on a per method basis. The first and the default is a "write" lock. Essentially with a write lock, the caller hold an exclusive lock on the bean for the duration of the method call and all other threads for that or any other method must wait. The other option is a "read" lock. The read lock allows full concurrent access to the methods (assuming no write locks are held). The default mode of WRITE will essentially make your bean a single-threaded bean, which is very slow. The more conservative @Lock(WRITE) as chosen as the default as this is how all the other bean types work (on a single thread may access a bean instance at any given time). Those that are aware of how to handle concurrent access can easily put @Lock(READ) on their bean class, thus changing the default, and then @Lock(WRITE) on specific methods if needed. We have an implementation of this in OpenEJB which I quite literally finished yesterday. I'd love to get some feedback for both the spec and for OpenEJB. It's the only @Singleton implementation in existence that I'm aware of and I'm pretty excited to see what people think. I've put together a snapshot build of the svn trunk for the group to try out along with the examples: http://people.apache.org/~dblevins/jug-indonesia/ Thanks again for the welcome and happy EJB'ing :) -David
