If you set DupsOK, duplicates are ok to be received...
The user will receive a message, and update the DB...
Say, for instance:
Db.update(balance = balance + message.getProperty("sale"));
Since it's DupsOK, you could eventually get a duplicate of the message, and
have an invalid balance generated.
You could say users should verify if this was duplicated or not... but
that's not the usual usage I have seen users doing...
Any user doing MDB will probably require XA and have the server avoiding
duplicates for him on that case.
You may say, there's a way to do that through standalone applications...
but I have failed to do that in 10 years, and I see most of the users
through support cases, and consulting engagements (when I used to do that
before I joined JBoss / RedHat) doing MDBs and XA.
I think the best way to help these users is to enable them to batch
transactions through MDBs, otherwise they will bound to one commit per
message received.. what makes performance really bad on both their
endpoints (database) and Message transactions.
On Thu, Aug 27, 2015 at 11:18 AM, Chris Barrow <chris.barrow_at_kaazing.com>
wrote:
> Hi Clebert,
>
> "DupsOK is ok, but that doesn't guarantee the semantic these users have."
>
> Sounds intriguing. Could you explain a bit more, maybe give a concrete use
> case?
>
> Chris
>
>
> On 8/27/2015 8:11 AM, Clebert Suconic wrote:
>
>
> On Thu, Aug 27, 2015 at 10:37 AM, Nigel Deakin <nigel.deakin_at_oracle.com>
> wrote:
>
>> Hi Clebert,
>>
>> We should definitely discuss how the JMS 2.0 proposals proposals for
>> batch delivery (since deferred) might work with the new-style MDBs and
>> listener beans.
>>
>> As you know, MDB users can turn off XA transactions using the
>> @TransactionManagement annotation, and can remove the number of network
>> round-trips using an acknowledgement mode of DUPS_OK. Why is this not
>> sufficient?
>>
>
> Because users want to have the messages and their Database operations in
> transaction.
> I have seen this pattern since my days of consultant.
>
> This goes beyond my JBoss. I'm not concerned about any specific usecase
> from JBoss, but from what I see from users doing on day by day with their
> messaging systems.
>
> DupsOK is ok, but that doesn't guarantee the semantic these users have.
>
>
>> Or do you have a specific need to have XA transactions that cover
>> multiple messages?
>
>
>
> From what I see, EE users will want to have async messages, but will need
> transactions.. the easiest way to do XA Transactions between JMS and
> Databases are through EE... for that reason, users are *over-using* MDBs...
> and XA transaction
>
> And that's limiting any improvements done by any messaging provider.
>
> A few handful users will write standalone application to batch things
> properly...
>
>
> So, I think we really should propose a way to batch things through MDBs.
> At least these users would take full advantage of asynchronous message
> systems and still do transactions.
>
>
>
>
>
>
--
Clebert Suconic