Re: deleting

I see that I consistently forgot to type "n't', geesh. The problem of course is that the one context is trying to remove a client while the other context won't (<- there it is) accept that.

Yes, I totally agree that JTA/XA is the answer, only my current client (project) has elected to use RoR for certain domains. Apparently it can't participate in XA.  So I'm trying to figure if there is a decent solution to that, or that I need to get really angry with the architect.

Tom


On 2013-07-11 10:00, Dennis Traub wrote:
> Delete a client? Is this what the business does? Or do you rather blacklist a client, mark a client as deceased, record that a former client never wants to be contacted again? Which might have different effects on how unpaid invoices are to be handled as well.
>
> Am 11.07.2013 um 07:57 schrieb Tom Eugelink <[email protected] <mailto:[email protected]>>:
>
>>
>> Suppose a context owns a certain aggregate and another uses it. Now the owning context is suppose to remove the aggregate and within its own context has no problem doing so. But the other context can agree with the removing of the aggrgate. An example would be some client administration context and an invoice context. The client may be removed, but as long as there are unpaid invoices, or even invoices to be created, the invoice context simply can handle a removed client.
>>
>> The question is; is there any good way to handle the setup without using distributed transactions (JMS with JTA/XA) and also without manually keeping track of acknowledgements that other contexts need to send before a client can be deleted?
>>
>> Tom
>>
>