[
https://issues.jboss.org/browse/JBTM-2422?page=com.atlassian.jira.plugin....
]
Mark Little commented on JBTM-2422:
-----------------------------------
So the reason I haven't allowed this is because the semantics of the class/object and
associated application may change dramatically between pessimistic and optimistic. The
developer needs to understand the differences and someone who created their classes using
optimistic, say, may not be the person who then uses them within a container years later
that tries to override this annotation.
I'd thought of allowing some annotations on classes/interfaces to override those of
the container or vice versa in general, i.e., not just specifically for optimistic or
pessimistic. For some it does make sense. For others not so much. Obviously we could
control this within the annotation itself by saying whether or not it allows being
overridden.
Consider @Optimistic/@Pessimistic annotations on the Container
--------------------------------------------------------------
Key: JBTM-2422
URL:
https://issues.jboss.org/browse/JBTM-2422
Project: JBoss Transaction Manager
Issue Type: Enhancement
Components: STM
Reporter: Tom Jenkinson
Assignee: Mark Little
Would it make sense for the container to be optionally marked as @Optimistic and
@Pessimistic thereby allowing an override of the behaviour requested by the object. The
scenario I am considering is if you imagine a library of STM objects developed by some
other team, could it be that the concurrency control of them is best defined by the app
and the easiest way to do that might be via Container.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)