Skip to content

[#225] introduce Transaction.Status enum and deprecate Status#226

Closed
gavinking wants to merge 4 commits intojakartaee:masterfrom
gavinking:#225
Closed

[#225] introduce Transaction.Status enum and deprecate Status#226
gavinking wants to merge 4 commits intojakartaee:masterfrom
gavinking:#225

Conversation

@gavinking
Copy link
Copy Markdown
Member

also give Synchronization default noop impls of its methods

for #225

also give Synchronization default noop impls of its methods

for jakartaee#225
@gavinking gavinking changed the title introduce Transaction.Status enum and deprecate Status [#225] introduce Transaction.Status enum and deprecate Status May 4, 2025
*
* @since JTA 2.1
*/
public Status getCurrentStatus() throws SystemException;
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe simply currentStatus() or status()? Wonder if the Javabean style is still required?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is something I've been thinking about recently. I had sorta decided that it made sense to go with the short form for things that are "like record fields", i.e. things that are by nature simple immutable values.

The tx status is mutable, so I would say stick with the old-style getter here.

A more aggressive strategy would be: "use the short form for everything which doesn't have a setter". But there's a couple of reasons to not go in that direction:

  1. we have so many legacy APIs which don't conform to that, and
  2. in some cases, you might want to add a setter later, or on a subtype.

Copy link
Copy Markdown
Member

@starksm64 starksm64 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this one better than mine. I was worried that not having a symbol different than Status would cause issues, but scoping it to Transaction class resolves this.

There is just one other location missing that should be updated, the javadoc in TransactionScoped.java:

  • UserTransaction.getCurrentStatus or
  • TransactionManager.getCurrentStatus
  • is one of the following states:
    • Transaction.Status.STATUS_ACTIVE
    • Transaction.Status.STATUS_MARKED_ROLLBACK
    • Transaction.Status.STATUS_PREPARED
    • Transaction.Status.STATUS_UNKNOWN
    • Transaction.Status.STATUS_PREPARING
    • Transaction.Status.STATUS_COMMITTING
    • Transaction.Status.STATUS_ROLLING_BACK

/**
* The equivalent legacy integer-valued code defined by {@link jakarta.transaction.Status}.
*/
public int code() {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not technically needed as you can just return Transation.Status.ACTIVE.ordinal() for example, but this would safeguard against a reordering of the enums breaking consistency with legacy Status constant value.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I was just being extra super-anal here.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't hurt.

* @since JTA 2.1
*/
enum Status {
/**
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the Status enum names were left exactly the same as the legacy jakarta.transaction.Status.STATUS_* constants, you could go a global search and replace to upgrade to enums. Many IDEs do support regex search and replace, so it still could be done and you would have less verbose enum names. It is probably better to drop the STATUS_ prefix from the enum names.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your concern is about renaming MARKED_ROLLBACK to MARKED_FOR_ROLLBACK and ROLLEDBACK to ROLLED_BACK, right?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really more of just leaving the names exactly as found in the legacy Status which means the the full STATUS_MARKED_ROLLBACK vs new MARKED_FOR_ROLLBACK. I'm really only thinking of if one wants to update an existing codebase to use the new enum. I'm iffy as to whether that is worth it.

@jta-bot
Copy link
Copy Markdown
Contributor

jta-bot commented Jun 5, 2025

Can one of the admins verify this patch?

@tomjenkinson
Copy link
Copy Markdown
Contributor

ok to test

* The equivalent legacy integer-valued code defined by {@link jakarta.transaction.Status}.
*/
public int code() {
switch (this) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the next feature release of Jakarta Transactions is part of the platform 12 which is targetting EE12 (https://jakartaee.github.io/platform/jakartaee12/JakartaEE12ReleasePlan), having talked to Gavin it sounds like this switch could be possible to refactor to switch expressions (hopefully then not needing the default to be defined). This is not a blocker but it might be nice

/**
* The equivalent legacy integer-valued code defined by {@link jakarta.transaction.Status}.
*/
public int code() {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having talked this through with Gavin, I think int is is really what is deprecated here and so we should either add this method as Deprecated or not add this method

Copy link
Copy Markdown
Contributor

@tomjenkinson tomjenkinson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for very much for the contribution to our project @gavinking ! I will share it on the mailing list for a few days for further reviews and merge it next week.

@tomjenkinson
Copy link
Copy Markdown
Contributor

Advertised to the community at https://www.eclipse.org/lists/jta-dev/msg00375.html

@gavinking
Copy link
Copy Markdown
Member Author

Closing in favor of #241 after rebasing.

@gavinking gavinking closed this Oct 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants