The solution in MboxMailRepository has problems too: it uses MD5 of the
message as the unique key. This means that 2 identical messages cannot
be handled by the same repository.
The problem is that a repository MUST be threadsafe and we must handle
correctly environments where messages are listed, retrieved and deleted
by multiple threads, by their names.
Currently each call to "list()" creates new names and forget the old
ones, so this is not safe.
Multiple calls to list will return different uniq code for the same
messages. This could not be a problem (to be verified). The problem is
then as soon as another list is done (by another concurrent thread for
example) the first thread will not be able to retrieve any message.
I don't know javamail "stores" enough to say what is the best way to
identify a message in the store.
Stefano
Norman Maurer wrote:
So im right that the problem is that a list() can override the unique
hash? So would it solve it when we just generate new ones when
uniqToMessageNumber has now entries ? or is that not the solution. I
just want to understand what is going on ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
