[timfox]

In short, if you want this semantic use 2PC.
There is no point building something complicated which is eventually
going to boil down to something more intensive than tranaction logging
anyway!

I think this is less intensive than tx logging since we only have to log the id rather than the entire tx state, also we don't have the extra client->server call for the prepare.

Another advantage is that it will work with existing (non 2PC) client applications. i.e. they don't have to rewrite their applications to use 2PC to take advantage of this extra level of QoS.

Having said, all that, this task isnt a major priority - most of our competitors don't provide this functionality, although at least one does (I have just googled).

[adrian.brock]

"timfox" wrote:

I think this is less intensive than tx logging since we only have to log the id rather than the entire tx state, also we don't have the extra client->server call for the prepare.

Are you sure? Writing a custom garbage collector sounds a lot more
complicated than using an already written and optimized transaction log in the
transaction manager.

Also, this is an additional overhead for people that deliberately
didn't select this QoS because they don't need it.

e.g. The body of the message already contains a unique id
that they need to check anyway because of the potential of a redelivery
after a failure.

[timfox]

Also, this is an additional overhead for people that deliberately
didn't select this QoS because they don't need it..

As I mentioned earlier in the thread, this would be off by default.

It would certainly be madness to have this as the default behaviour :)

[timfox]

Another thing we could do is to provide duplicate message detection only for the lifetime of a particular session.

The user could create a session with a special parameter, and then the server would ensure no duplicates were sent by consulting a cache of ids in memory.

Since it's in memory no persistence would be required, basically it would just be an extra hashmap lookup.