Re: Singleton Container

[David Blevins <da...@visi.com>]

On Jun 28, 2008, at 2:10 PM, David Blevins wrote:

> When we add that functionality we'll want to make an option on the  
> container to control how long a calling thread should wait till  
> timeout occurs and a ConcurrentAccessTimeoutException is thrown.   
> Any thoughts on what the default timeout should be?  Couple seconds,  
> couple minutes, infinite?

Went with 30 seconds.  Added some functionality so that people can  
specify this as "30s" "30 seconds" "1000ms" "1000 milliseconds".  Even  
supports singular "1 second".

> The spec group hasn't determined what the related xml is for  
> declaring bean vs container concurrency management, so we'll have to  
> make something up.  Same goes for how to specify the "concurrency  
> attribute" of a bean's methods.  Any ideas on what the xml should  
> look like?

Ended up modeling it completely after the transaction related  
annotations.  So that gives us:

  <concurrency-type>Bean</concurrency-type>
  <concurrency-type>Container</concurrency-type>

  <assembly-descriptor>
    <container-concurrency>
      <method>
        <ejb-name>SomeEJB</ejb-name>
        <method-name>*</method-name>
      </method>
      <concurrency-attribute>ReadOnly</concurrency-attribute>
    </container-concurrency>
  </assembly-descriptor>

One thing to note is that the annotations we now support:

   @ConcurrencyManagement(BEAN)
   @ConcurrencyManagement(CONTAINER)
   @Lock(READ)
   @Lock(WRITE)

...are different than the ones in the draft spec:

   @BeanManagedConcurrency
   @ContainerManagedConcurrency
   @ReadOnly
   @ReadWrite

I don't particularly care for these and am trying to get them  
changed.  1) They don't match any of the existing javax.ejb.  
annotations like @TransactionManagement or @TransactionAttribute. 2)  
Nothing stops you from mistakenly using both @ReadOnly and @ReadWrite  
on the same class or method.  3) Requires the user to learn via docs  
and remember that @ReadOnly and @ReadWrite apply to the same "logical  
group" and are mutually exclusive and that the default is @ReadWrite  
-- all of this can be communicated with the @Option(Enum) style  
annotation.

Side benefit is that it's way easier to process as we only have to  
look for two annotations (@ConcurrencyManagement and @Lock) vs four  
(@BeanManagedConcurrency/@ContainerManagedConcurrency and @ReadOnly/ 
@ReadWrite).


-David

Re: Singleton Container

[Mohammad Nour El-Din <no...@gmail.com>]

I think David Blevins can suggest those proposed annotations to the
EG, right David ?

On Wed, Jul 2, 2008 at 5:00 PM, Karan Malhi <ka...@gmail.com> wrote:
>>
>>
>> One thing to note is that the annotations we now support:
>>
>>  @ConcurrencyManagement(BEAN)
>>  @ConcurrencyManagement(CONTAINER)
>>  @Lock(READ)
>>  @Lock(WRITE)
>>
>> ...are different than the ones in the draft spec:
>>
>>  @BeanManagedConcurrency
>>  @ContainerManagedConcurrency
>>  @ReadOnly
>>  @ReadWrite
>>
>
> Very cool, our annotations are defintely better than the draft
> specification. Would be great if they change the ones in the draft and
> replace them with what you have added.
> --
> Karan Singh Malhi
>



-- 
Thanks
- Mohammad Nour

Re: Singleton Container

[Karan Malhi <ka...@gmail.com>]

>
>
> One thing to note is that the annotations we now support:
>
>  @ConcurrencyManagement(BEAN)
>  @ConcurrencyManagement(CONTAINER)
>  @Lock(READ)
>  @Lock(WRITE)
>
> ...are different than the ones in the draft spec:
>
>  @BeanManagedConcurrency
>  @ContainerManagedConcurrency
>  @ReadOnly
>  @ReadWrite
>

Very cool, our annotations are defintely better than the draft
specification. Would be great if they change the ones in the draft and
replace them with what you have added.
-- 
Karan Singh Malhi