[
https://issues.apache.org/jira/browse/JAMES-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518927
]
Robert Burrell Donkin commented on JAMES-802:
---------------------------------------------
If we opt for read-write locking then the design of the locking needs to be
considered. The illustrative patch does not time out threads. Is timing out a
better idea?
> [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]
