| Hi Scott-
What does ‘readOnly’ mean in this context? More specifically— Do you have a concrete use-case that would involve messaging to provide additional context?
Questions:
Is the intent to be ‘read-only’ or ’not impacting data change anywhere’?
What would be the expected behavior if the first message on the queue was malformed? Would the consumer reject the message (then it would be the same message the next time through) or move the message to a dead-letter-queue and try to see if the next message was valid?
Is there an expectation that no state changes (across all resources) between ‘read’ message will be there if a subsequent ‘write’ transaction occurs after the readOnly completes? (ie timing / race condition)
From the messaging perspective, ‘readOnly’ could be interpreted different ways:.
1. A messaging consumer is read-only from the perspective of the queue-to-the-application.
- or -
2. A messaging consumer could be considered a data changing operation from the perspective of the queue-only (the queue now has less message(s)).
- or -
3. Browse message(s) in a transaction— no guarantee the they will be there if the app tries to immediately open a consumer after browsing, since another consumer may have processed them in the time between (aka race condition).
Thanks, Matt Pavlovich On Nov 7, 2025, at 7:58 AM, Scott Marlow via messaging-dev <messaging-dev@xxxxxxxxxxx> wrote:
Dear Jakarta Messaging specification team,
The Jakarta EE 12 Platform will include Jakarta Transactions 2.1 which includes readOnly hint added to the `jakarta.transaction.Transactional` annotation [1][2] which users.
I'm going to paste some specification text from the [3] pull request that describes the expected action to be taken if read-only mode is enabled for a XAResource: " If the current transaction is in the read-only mode, the transaction manager tries to put the enlisted resource in the read-only mode by invoking the `ExtendedXAResource#setReadOnly` method if it implements the `ExtendedXAResource` interface. If the `ExtendedXAResource` cannot be put into read-only mode or the `XAResource` does not implement the `ExtendedXAResource` interface, the transaction manager must roll back the `XAResource` at transaction commit. "
Could the Messaging specification team please respond with feedback on this new read-only feature and whether the EE 12 Platform specification text should mention any Messaging features that are not expected to support read-only transactions? If yes, which Messaging features will not work with read-only transactions? Also if yes, should we open a Messaging (4.0) issue to add changes to support read-only transactions?
For example, could QueueBrowser always work in an active transaction with a (read-only mode enabled) ExtendedXAResource? More specifically could a Messaging implementation expect to update the database during the queue browse operation? I find it unlikely that any implementation would update the (queue) database during a browse operation but want to hear your feedback on whether that would be allowed? One possible reason for updating the application database is to save QueueBrowser statistics to the application database.
Perhaps we can come up with generic EE 12 Platform text to describe that any database update performed against a read-only Resource will not be saved or something like that to cover ^ and operations like that. Still, I'we are looking to better understand the possible cases and what can be expected to work/not work.
Thanks, Scott
Note that there is a Connectors issue [4] open as well.
Thanks, Scott
_______________________________________________ messaging-dev mailing list messaging-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://accounts.eclipse.org
|
