[
https://issues.apache.org/jira/browse/OFBIZ-5213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678001#comment-13678001
]
Christoph Neuroth commented on OFBIZ-5213:
------------------------------------------
Yes we should definitely get rid of exception regarding the ServiceSemaphore
entity which is the root cause here, but I haven't found out yet why it occurs:
there are no find calls with cache:true to be found. The only usage of the
entity is in the ServiceSemaphore class itself where it is created and deleted.
Nonetheless I think my patch is valuable by itself because it simplifies
debugging and results in less entities that are not rolled back when this
occurs...
> Continue to rollback transactions after IllegalStateException
> -------------------------------------------------------------
>
> Key: OFBIZ-5213
> URL: https://issues.apache.org/jira/browse/OFBIZ-5213
> Project: OFBiz
> Issue Type: Bug
> Components: framework
> Affects Versions: SVN trunk
> Reporter: Christoph Neuroth
> Attachments: OFBIZ-5213.patch
>
>
> Since Adrians recent changes (probably the new mutability check in
> EntityListCache#put), we had some cases where GenericDelegator.rollback()
> failed because one of the testOperations tries to remove a ServiceSemaphore
> entity and fails because of the IllegalStateException thrown in
> GenericEntity#assertIsMutable. Because this exception is not caught in the
> rollback method, all following entities are not rolled back, which leaves the
> database in an inconsistent state and causes failures in later tests.
> I'm attaching a patch which will continue to rollback other entities in this
> case and report an error with the number of failed operations afterwards.
> Note that an alternative implementation of this would be to throw a checked
> exception extending from GenericEntityException so the additional catch is
> not required, but I wasn't sure which would fit better to the OFBiz way of
> doing exception handling.
> The patch also includes the entity name in the exception for a bit easier
> debugging and removes the logging from a log-and-throw because that caused
> the exception + stacktrace to be logged twice.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
