[ 
https://issues.apache.org/jira/browse/ISIS-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oscar Bou updated ISIS-1476:
----------------------------
    Description: 
That way we avoid casting from "Transaction" to "IsisTransaction", and can 
support use cases that properly handle the Exception without further 
consequences.

For example, creating an idempotent action that first tries to create an object 
and, if an SQLIntegrityConstraintViolationException occurs, return the 
previously persisted entity, avoiding one SELECT on massive bulk actions.

{code}
 // {{ addMessage (action)
    @Action(semantics=SemanticsOf.IDEMPOTENT)
    public Message addMessageIdempotent(
            final String receiptHandle, final String notificationId,
            final Clob xmlContent, final String notificationType, 
            final DateTime publishTime, final String payloadVersion) {
        Notification unprocessedNotification = null;

        try {
            unprocessedMessage = this.wrap(this).createMessage(receiptHandle,
                    notificationId, amazonMarketplace, xmlContent,
                    notificationType, publishTime, payloadVersion, sellerId);
        } catch (final JDODataStoreException e) {
            if (Iterables.filter(Throwables.getCausalChain(e),
                    SQLIntegrityConstraintViolationException.class) != null) {

                ((IsisTransaction) this.transactionService.currentTransaction())
                        .clearAbortCause();

                unprocessedMessage = this.wrap(this).findByReceiptHandle(
                        receiptHandle);
            } else {
                throw e;
            }
        }

        return unprocessedMessage;

    }

    // }}
{code}


If published in the "Transaction" interface, the casting can be avoided, being 
simply:

{code}
                this.transactionService.currentTransaction()
                        .clearAbortCause();
{code}


  was:
That way we avoid casting from "Transaction" to "IsisTransaction", and can 
support use cases that properly handle the Exception without further 
consequences.

For example, creating an idempotent action that first tries to create an object 
and, if an SQLIntegrityConstraintViolationException occurs, return the 
previously persisted entity, avoiding one SELECT on massive bulk actions.

{code}
 // {{ addMessage (action)
    @Action(semantics=SemanticsOf.IDEMPOTENT)
    public Message addMessageIdempotent(
            final String receiptHandle, final String notificationId,
            final Clob xmlContent, final String notificationType, 
            final DateTime publishTime, final String payloadVersion) {
        Notification unprocessedNotification = null;

        try {
            unprocessedMessage = this.wrap(this).createMessage(receiptHandle,
                    notificationId, amazonMarketplace, xmlContent,
                    notificationType, publishTime, payloadVersion, sellerId);
        } catch (final JDODataStoreException e) {
            if (Iterables.filter(Throwables.getCausalChain(e),
                    SQLIntegrityConstraintViolationException.class) != null) {

                ((IsisTransaction) this.transactionService.currentTransaction())
                        .clearAbortCause();

                unprocessedMessage = this.wrap(this).findByReceiptHandle(
                        receiptHandle);
            } else {
                throw e;
            }
        }

        return unprocessedMessage;

    }

    // }}
{code}



> Transaction interface: Expose "clearAbortCause" for avoiding handled 
> persistence Exceptions
> -------------------------------------------------------------------------------------------
>
>                 Key: ISIS-1476
>                 URL: https://issues.apache.org/jira/browse/ISIS-1476
>             Project: Isis
>          Issue Type: Improvement
>            Reporter: Oscar Bou
>            Assignee: Oscar Bou
>
> That way we avoid casting from "Transaction" to "IsisTransaction", and can 
> support use cases that properly handle the Exception without further 
> consequences.
> For example, creating an idempotent action that first tries to create an 
> object and, if an SQLIntegrityConstraintViolationException occurs, return the 
> previously persisted entity, avoiding one SELECT on massive bulk actions.
> {code}
>  // {{ addMessage (action)
>     @Action(semantics=SemanticsOf.IDEMPOTENT)
>     public Message addMessageIdempotent(
>           final String receiptHandle, final String notificationId,
>           final Clob xmlContent, final String notificationType, 
>           final DateTime publishTime, final String payloadVersion) {
>       Notification unprocessedNotification = null;
>       try {
>           unprocessedMessage = this.wrap(this).createMessage(receiptHandle,
>                   notificationId, amazonMarketplace, xmlContent,
>                   notificationType, publishTime, payloadVersion, sellerId);
>       } catch (final JDODataStoreException e) {
>           if (Iterables.filter(Throwables.getCausalChain(e),
>                   SQLIntegrityConstraintViolationException.class) != null) {
>               ((IsisTransaction) this.transactionService.currentTransaction())
>                       .clearAbortCause();
>               unprocessedMessage = this.wrap(this).findByReceiptHandle(
>                       receiptHandle);
>           } else {
>               throw e;
>           }
>       }
>       return unprocessedMessage;
>     }
>     // }}
> {code}
> If published in the "Transaction" interface, the casting can be avoided, 
> being simply:
> {code}
>               this.transactionService.currentTransaction()
>                       .clearAbortCause();
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to