[
https://issues.apache.org/jira/browse/JAMES-2942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier closed JAMES-2942.
---------------------------------
Resolution: Fixed
This should be fixed by more recent James versions.
reopen if it is not the case.
Regards,
Benoit
> Unable to perform range deletes with JPA
> ----------------------------------------
>
> Key: JAMES-2942
> URL: https://issues.apache.org/jira/browse/JAMES-2942
> Project: James Server
> Issue Type: Bug
> Components: jpa
> Environment: Amazon EC2 Linux 2.
> Reporter: Jerry Malcolm
> Priority: Major
> Fix For: 3.4.0
>
>
> Every time I try to trash more than one mail item at a time (select a bunch
> of mails in TBird and hit 'Delete') I get a failure. The logs have a huge
> dump which I can attach
> if necessary. But the key lines are:
> Caused by: <openjpa-3.0.0-r422266:1833209 fatal store error>
> org.apache.openjpa.persistence.RollbackException: Optimistic locking
> errors were detected when flushing to the data store. The following
> objects may have been concurrently modified in another transaction:
> [org.apache.james.mailbox.jpa.mail.model.JPAUserFlag-1530940342]
> Caused by: <openjpa-3.0.0-r422266:1833209 nonfatal store error>
> org.apache.openjpa.persistence.OptimisticLockException: An optimistic
> lock violation was detected when flushing object instance
> "org.apache.james.mailbox.jpa.mail.model.JPAUserFlag-1530940342" to the
> data store. This indicates that the object was concurrently modified in
> another transaction.
> I understand locking, etc. I googled 'optimistic lock' but I'd have to
> dig deeper to understand how it's used in JPA. In any case, apparently
> these locks are fighting with each other when more than one update is
> attempted on a mailbox.
> This is very reproducible. So far, I have never been able to delete
> more than one item at a time.
> And note that does not only occur with a range delete. If I repeatedly,
> quickly hit the delete key on several emails, I get the error as well. So it
> appears the failure simply occurs if a second delete (or folder move) is
> started before the previous delete has completed.
> I guess my current version is in the ballpark of 3.4+. It was a clone
> of the master branch right after 3.4 went live.
> I have not added any additional user flags to the emails being deleted.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
