[
https://issues.apache.org/jira/browse/QPID-7646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16185958#comment-16185958
]
Keith Wall commented on QPID-7646:
----------------------------------
In addition, the model statistics {{Session#getTransactionStartTime}} and
{{Session#getTransactionUpdateTime}} do not make sense from an AMQP 1.0
perspective as transactions are logically associated with the Connection. I
don't think it make sense to tackle the above without addressing this too.
I think internally all connections should expose the set of currently open
transactions. For AMQP 1.0, this is simply
AMQPConnection_1_0#getOpenTransactions(). For the older protocols this would
expose the transactions associated with the open sessions. The transaction
timeout feature should observe the open transactions through the connection.
This would add support for transaction timeout feature for AMQP 1.0. We would
need to decide the correct behaviour for an AMQP 1.0 connection to communicate
the transaction timeout back to the coordinator. I notice that the spec has
provision for the for the coordinator link to be closed in certain situations
(but this would be a spontaneous close from the coordinator perspective). It
could of course simple close the connection.
I am not sure if there is benefit for continuing to expose transaction start
and update times through the model. It did cross my mind that we could have
Set<Transactions> Connection#getOpenTransaction() where Transaction would be a
ManagedAttributeValue, but I question whether this is necessary from a user
perspective. Perhaps just the count of open transactions is sufficient.
> [Java Broker] fix AbstractAMQPSession#getLocalTransactionOpen to support
> values > 1
> -----------------------------------------------------------------------------------
>
> Key: QPID-7646
> URL: https://issues.apache.org/jira/browse/QPID-7646
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> During the review of QPID-7633 it was noted:
> bq. Why do we only return 0 or 1 from
> AbstractAMQPSession#getLocalTransactionOpen. That seems wrong.
> which was followed up by Rob:
> bq. On getLocalTransactionOpen, I agree that looks very dodgy. In AMQP 0-x
> the value will only be 0 or 1, but I'm not sure the implementation the we
> have now is safe. I think the implementations will need to define this
> properly (i.e. the calculation will need to be atomic, and the value may be >
> 1 for AMQP 1.0 )
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
