On Sun, Jun 29, 2008 at 12:10 AM, David Blevins <[EMAIL PROTECTED]> wrote:
> Ok. So... what's there is basically the stateless container with a couple
> tweaks so that it doesn't remove instances and only allows one instance per
> bean.
>
> Here's what we don't yet support. Will be making more jiras for these.
>
>
> -----------------------------------
> CONCURRENCY
> -----------------------------------
>
> - @BeanManagedConcurrency
> - @ContainerManagedConcurrency
> - @ReadOnly (shared access)
> - @ReadWrite (exclussive access), the default
> - ConcurrentAccessTimeoutException
>
> The functionality we have now in regards to concurrency is compliant with
> Container-Managed Concurrency and method default of ReadWrite. I.e. only
> one person can use the singleton at a time. It'll be a bit of work to break
> that up to support locking on a per method basis. That'll be doable with
> the java.util.concurrent.locks.ReentrantReadWriteLock class.
>
> 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?
>
> 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?
* For container managed concurrency:
<concurrency>CMC</concurrency>
* For bean managed concurrency
<concurrency>BMC</concurrency>
>
> -----------------------------------
> STARTUP
> -----------------------------------
>
> - @Startup
>
> Right now, the instances are created lazily when you first look them up.
> Startup could be easily supported by just instantiating the bean when the
> Container's deploy(DeploymentInfo) method is called.
>
> We could add an option on the container so people can control which they'd
> like to do by default. Any thoughts on what the default default should be?
> I.e. first access (lazy) or at startup?
I would choose *lazy* to be the default for startup efficiency of the
OEJB system. And to give the users a JVM property to control this
default loading policy of the OEJB system for singleton beans.
>
> Again the spec group hasn't determined the ejb-jar.xml xml for specifying if
> the singleton bean should be loaded on startup. Any ideas?
* For loading on startup :
<on-startup>true</on-startup>
* For not loading on startup:
<on-startup>false</on-startup>
>
>
> -----------------------------------
> ORDERING
> -----------------------------------
>
> - @DependsOn(String[])
>
> Right now, we just load the beans in the order they are declared in the
> ejb-jar.xml or discovered in the jar. The @DependsOn allows you to list the
> ejbs that should be loaded before the bean in question. You can list beans
> by ejb-name.
>
> There are no real configurable options for this functionality that I see.
>
> Again the spec group hasn't determined the ejb-jar.xml xml for specifying if
> the "@DependsOn" data in the deployment descriptor. Any ideas?
We can use this XML - same like dependencies defined in Maven but I
will use the same name used in the annotation for consistency:
<depends-on>
<dependency>
EJB1_NAME
</dependency>
<dependency>
EJB2_NAME
</dependency>
<dependency>
EJB_JAR3#EJB3_NAME
</dependency>
<dependency>
EJB_JAR4#EJB4_NAME
</dependency>
</depends-on>
>
>
>
> -David
>
>
>
>
>
--
Thanks
- Mohammad Nour
