weird since it was fine for me

but i know parent methods of a singleton are by default WRITE even if the
child is READ and i guess that's the same for intrefaces so i'm not sure of
the fix

- Romain


2012/7/5 AndyG <[email protected]>

> I have changed BeanContext to perform the check only for a singleton.
>
> The BeanContext is used here:
> org.apache.openejb.core.singleton.SingletonContainer#_invoke
>
> boolean read =
>
> javax.ejb.LockType.READ.equals(beanContext.*getConcurrencyAttribute*(runMethod));
>
> This result was wrong for a singleton where the class or interface is
> defined with javax.ejb.LockType.READ (i.e, NOT the default) - Methods that
> are not explicitly @Lock annotated should/must inherit the class/interface
> definition for @Lock. They were not, as it was hard coded
> javax.ejb.LockType.WRITE
>
> The org.apache.openejb.BeanContext#initDefaultLock checks for the default -
> You probably know a better way to do this, but the result is required for
> the variable 'this.lockType' - Please improve it, but I assure you this
> variable must be dynamic for a singleton and not hard coded.
>
> The example: http://openejb.apache.org/examples-trunk/simple-singleton/was
> not working as described...
>
> @Singleton
> @Lock(READ)
> public class ComponentRegistry {
>
> public Collection<?> getComponents() {... <-- Was NOT inheriting
> @Lock(READ)
> it was @Lock(WRITE)
>
>
> This was causing issues for me where a WRITE lock was blocking a concurrent
> READ, which it should not.
>
> Andy.
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/Re-svn-commit-r1357576-in-openejb-trunk-openejb-container-openejb-core-src-main-java-org-apache-opena-tp4656048p4656053.html
> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>

Reply via email to