[
https://issues.apache.org/jira/browse/JAMES-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Burrell Donkin updated JAMES-802:
----------------------------------------
Attachment: torque-locking.patch
Note: this patch is from my local fork. It is intended for illustrative
purposes only.
> [torque] Mailbox Currency
> -------------------------
>
> Key: JAMES-802
> URL: https://issues.apache.org/jira/browse/JAMES-802
> Project: James
> Issue Type: Bug
> Components: IMAPServer
> Environment: torque -> derby
> Reporter: Robert Burrell Donkin
> Attachments: torque-locking.patch
>
>
> Whilst running fetchmail->SIEVE->IMAP concurrently with an IMAP client, the
> following exception frequently occurred:
> org.apache.torque.TorqueException: java.sql.SQLTransactionRollbackException:
> A lock could not be obtained due to a deadlock
> My diagnosis is that the torque mailbox cannot read and write concurrently.
> I've been running for a few weeks with concurrent utils read-write locking
> code in the mailbox and this exception has not again occurred. I will attach
> the patch I'm running on my local JAMES fork. I think the time is right to
> consider adding read-write locking on trunk.
> Disadvantages (of introducing read-write locking):
> * Using a programmatic read-write lock will reduce throughput in a
> multi-user environment. The granularity is necessarily course.
> * May introduce subtle programmatic deadlock or thread-starvation
> conditions. This may be difficult to diagnose.
> * There is no proof that it effects other databases
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
