[
https://issues.apache.org/jira/browse/ARTEMIS-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17583167#comment-17583167
]
Justin Bertram commented on ARTEMIS-3949:
-----------------------------------------
bq. It would however be really useful to have such things documented somewhere,
especially since it is not clear from the interfaces that the session and all
children objects need to be accessed from the same thread.
For what it's worth, this _is_ documented in the [JavaDoc for
{{org.apache.activemq.artemis.api.core.client.ClientSession}}|https://activemq.apache.org/components/artemis/documentation/javadocs/javadoc-latest/org/apache/activemq/artemis/api/core/client/ClientSession.html].
Although it doesn't elaborate, it specifically says:
bq. A ClientSession is a *single-thread* object required for producing and
consuming messages. [emphasis mine]
This would also pop up in any IDE which parses JavaDoc for tool-tips, etc.
(e.g. IntelliJ IDEA, Eclipse, etc.).
> Internally synchronize methods in ClientSession implementations
> ---------------------------------------------------------------
>
> Key: ARTEMIS-3949
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3949
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Affects Versions: 2.24.0
> Reporter: Peter Machon
> Priority: Major
>
> {{ClientSessionImpl}} has two internal functions i.e. {{startCall}} and
> {{{}endCall{}}}. These function count concurrent access and throw in case of
> concurrent access.
> They are used e.g. in {{{}ClientProducerImpl{}}}s {{doSend}} method and in
> the {{ClientSessionImpls}} {{acknowledge}} method.
> This forces user code to synchronize the use of the session object. That is a
> pain for two reasons:
> 1. From a user perspective it is not even clear, which methods are internally
> counting concurrent access. E.g. the `doSend` method does not even belong to
> the session.
> 2. The session object is not accessible from the user code at any time. E.g.
> the {{ClientMessageImpl}} internally uses the {{{}ClientSession{}}}s
> {{acknowledge}} method. From user code it is not necessarily clear which
> session the `ClientMessage` belongs to.
> Thus, it would require user code to e.g. implement their own message store
> just to be able to synchronize the right session.
> Solution:
> The {{ClientSessionImpl}} and all other internal objects like
> {{{}ClientProducerImpl, ClientMessageImpl{}}}, and similar have full access
> and knowledge about their synchronization needs.
> I thus suggest to implement synchronization where needed instead of leaving
> the user alone with this issue, where the solution actually means to
> reimplement a lot of functionality of the client.
> E.g.
> {{startCall();}}
> {{try {}}
> {{sessionContext.sendACK(false, blockOnAcknowledge, consumer, message);}}
> {{} finally {}}
> {{endCall();}}
>
> could be replaced with something like
> {{synchronized(this) {}}
> {{sessionContext.sendACK(false, blockOnAcknowledge, consumer, message);}}
> {{} }}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
