[jira] Commented: (IMAP-193) UIDNEXT generation is a big performance killer and should get reworked

["Norman Maurer (JIRA)" <se...@james.apache.org>]

    [ https://issues.apache.org/jira/browse/IMAP-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913684#action_12913684 ] 

Norman Maurer commented on IMAP-193:
------------------------------------

Ok, I think I found a good solution for this after thinking a bit about it today. Its so "simple" that it was really hard to get it ;)

So here what we should do:
* Let us remove the Mailbox.getLastUid() method and not make it persistent. 
* Simply return "1" when the Mailbox is selected first. After that on the next append to the mailbox we can set the nextUid value to returned uid + 1. 
* Register a MailboxListener to the Mailbox when selecting it to get notified by append operations to the mailbox (in concurrent sessions) and set it when a append happen.

Then the implementations are free to use whatever method/pattern they like to generate the uid on append. For example in JPA we could just use a auto_increment field. This would allow us to get rid of locking the row and so give better performance. For sure we need to update the unit tests to allow this kind of generation of uid when append.

I think this is a way better then what we do now and is fully rfc conform (See RFC snipped in previous comment)

WDYT ?
        

> UIDNEXT generation is a big performance killer and should get reworked
> ----------------------------------------------------------------------
>
>                 Key: IMAP-193
>                 URL: https://issues.apache.org/jira/browse/IMAP-193
>             Project: JAMES Imap
>          Issue Type: Improvement
>            Reporter: Norman Maurer
>            Assignee: Norman Maurer
>
> In the store api we generate the uid for a new message and guaranteer that the Mailbox.getLastUid() method will return this value after it is stored. For this we save the message and the mailbox and use for example a row lock (in jpa land) for this to get rid of ghost-reads etc. 
> This is a big performance killer and is not needed at all. In the rfc its clearly stated that the used uid for the next saved message must just be equal or bigger then the UIDNEXT value. 
> From rfc:
>         Note: The next unique identifier value is intended to
>         provide a means for a client to determine whether any
>         messages have been delivered to the mailbox since the
>         previous time it checked this value.  It is not intended to
>         provide any guarantee that any message will have this
>         unique identifier.  A client can only assume, at the time
>         that it obtains the next unique identifier value, that
>         messages arriving after that time will have a UID greater
>         than or equal to that value.
>  

-- 
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org