[
https://issues.jboss.org/browse/JBTM-970?page=com.atlassian.jira.plugin.s...
]
Paul Robinson updated JBTM-970:
-------------------------------
Description:
The RequestType attribute on the ServiceRequest annotation identifies whether the service
request is always read only as far as transactional modifications are concerned or,
alternatively, that it may make changes to transactional data. in the latter case the
service request method can indicate a read-only outcome by invoking the readOnly method of
an injected control.
{code}
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface ServiceRequest
{
public RequestType requestType() default RequestType.MODIFY;
}
{code}
The framework does not normally register lifecycle callbacks for ServiceRequest methods
whose request type is READ_ONLY (see the next paragraph for the rider which qualifies this
statement). The framework does normally register callbacks for ServiceRequest methods
whose request type is MODIFY, on the assumption that the method has performed
transactional changes. The latter methods may inhibit registration of lifecycle methods by
calling the readOnly() method of an injected transaction control.
The reason why it is important to identify READ_ONLY methods is that they affect the way
the framework performs PREPARE or COMPLETE processing (as appropriate to the protocol in
question). If all ServiceRequest methods in the transaction are READ_ONLY the participant
will trigger READ_ONLY or EXIT callbacks, respectively, for these lifecycle events,
precluding further involvement in the transaction. If any of the ServiceRequest methods is
not READ_ONLY then the framework will trigger PREPARE or COMPLETE callbacks, respectively.
Clearly, it would be futile for a READ_ONLY declaration or notification to inhibit
registration of callbacks which are triggered by READ_ONLY or EXIT events. So, the
framework only registers READ_ONLY or EXIT lifecycle callbacks when they are triggered by
READ_ONLY methods or by MODIFY methods which notify their READ_ONLY status using an
injected control.
was:
This class level annotation allows the class which is the target of lifecycle handler
callbacks to be specified.
{code}
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface ParticipantService
{
public Class lifecycleClass() default Default.class;
}
{code}
This field may be overridden in the ServiceRequest annotation itself. If the value of this
field is Default.class then the ParticipantService class is used as the default class to
resolve POJO lifecycle methods.
{code}
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD, ElementType.TYPE})
public @interface ServiceRequest
{
public Class lifecycleClass() default Default.class;
}
{code}
If the lifecycleClass attribute is not specified in either place, the class containing the
@ServiceInvocation is assumed to also contain the associated Lifecycle Handler methods.
Allow a ServiceRequest to be annotated as read only
---------------------------------------------------
Key: JBTM-970
URL:
https://issues.jboss.org/browse/JBTM-970
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: TxBridge
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.M2
The RequestType attribute on the ServiceRequest annotation identifies whether the service
request is always read only as far as transactional modifications are concerned or,
alternatively, that it may make changes to transactional data. in the latter case the
service request method can indicate a read-only outcome by invoking the readOnly method of
an injected control.
{code}
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface ServiceRequest
{
public RequestType requestType() default RequestType.MODIFY;
}
{code}
The framework does not normally register lifecycle callbacks for ServiceRequest methods
whose request type is READ_ONLY (see the next paragraph for the rider which qualifies this
statement). The framework does normally register callbacks for ServiceRequest methods
whose request type is MODIFY, on the assumption that the method has performed
transactional changes. The latter methods may inhibit registration of lifecycle methods by
calling the readOnly() method of an injected transaction control.
The reason why it is important to identify READ_ONLY methods is that they affect the way
the framework performs PREPARE or COMPLETE processing (as appropriate to the protocol in
question). If all ServiceRequest methods in the transaction are READ_ONLY the participant
will trigger READ_ONLY or EXIT callbacks, respectively, for these lifecycle events,
precluding further involvement in the transaction. If any of the ServiceRequest methods is
not READ_ONLY then the framework will trigger PREPARE or COMPLETE callbacks, respectively.
Clearly, it would be futile for a READ_ONLY declaration or notification to inhibit
registration of callbacks which are triggered by READ_ONLY or EXIT events. So, the
framework only registers READ_ONLY or EXIT lifecycle callbacks when they are triggered by
READ_ONLY methods or by MODIFY methods which notify their READ_ONLY status using an
injected control.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira