[
https://issues.apache.org/jira/browse/MAILBOX-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Norman Maurer resolved MAILBOX-110.
-----------------------------------
Resolution: Fixed
I think we did everything we can in the api
> Possible race-condition because of lazy fetching
> ------------------------------------------------
>
> Key: MAILBOX-110
> URL: https://issues.apache.org/jira/browse/MAILBOX-110
> Project: James Mailbox
> Issue Type: Bug
> Components: api, store
> Affects Versions: 0.3
> Reporter: Norman Maurer
> Assignee: Norman Maurer
> Fix For: 0.4
>
>
> From ml:
> Hi there,
> today I tried to stress-test james IMAP and see how it behaves. During
> this I noticed there is a possible race-condition when concurrent
> access a mailbox from many clients.
> So let me explain what happens:
> * The first client fetch a ranges of mails (say 1:5000)
> * The second client does at the same time set the \DELETED flag on
> message with msn 4500 and then trigger "EXPUNGE".
> If the second client was able to execute the EXPUNGE before the first
> was trying to return message 4500 it will cause prolly cause problems
> to client one. As it will maybe try to get the headers in lazy fashion
> (like for example load them via JPA because they are declared via
> @LOB). This will fail as these rows not exist anymore.
> The same scenario can gives problems with maildir impls as the message
> file may not exist anymore.
> So to fix this we should prolly allow to Lock a Mailbox while
> accessing data from it. The best would be a read and a write lock. So
> we could be quick in read only cases. This will for sure add some
> overhead but I think its the best todo.
> WDYT ?
> Bye,
> Norman
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
