Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [messaging-dev] Impact of Read-only transactions on Messaging 3.1 applications?

Hey all,

roughly speaking, the intent of "read-only" is that operations within such a transaction may not change data in any form.

From a Jakarta Messaging perspective I would say that the only reasonable usage of a read-only transaction I can imagine is with the QueueBrowser when messages are just viewed, but never altered, removed or moved.

Is it possible/sensible to have a MessageConsumer that is read-only i.e. never changes the state of messages but just browses through them?Unless you think it is useful, I think we can limit the discussion to QueueBrowser.

The read-only nature does not impose any other semantics. So any concerns about race conditions, or more broadly speaking transaction isolation, are irrelevant.

Regards,

Christian

Am 08.11.2025 um 20:36 schrieb Matt Pavlovich via messaging-dev:
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:



On Thu, Nov 6, 2025 at 1:31 PM Scott Marlow <scott.marlow.opensource@xxxxxxxxx> 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

[1] https://github.com/jakartaee/transactions/issues/220 - tracking issue for readOnly.
[2] https://github.com/jakartaee/transactions/pull/222  - adds read-only transactions to Transaction spec + spec api.
[4] https://github.com/jakartaee/connectors/issues/168 - Implications of read-only transactions on Jakarta Connectors specification.
_______________________________________________
messaging-dev mailing list
messaging-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org


_______________________________________________
messaging-dev mailing list
messaging-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org

Back to the top