Sending events at the end of a transaction

Question

I have an interface for a Service object that looks something like the following (simplified for brevity):

public interface ItemService {

  public Item getItemB         


        

Answer 1

As @Wouter mentioned one alternative is using asynchronous messaging techniques. I can think of 2 other approaches:

1. the events fired by ItemService get stored in database table after commit (so on rollback they are not avialable). A background (async) job examines the events and calls the appropriate services. You could call it 'selfmade JMS'. Possible alternative if messaging infrastructure is not available.
2. Use a ThreadLocal to temporarily queue all the events and after the composite transactions commited, fire the events. This is not persistent and may fail, e.g. after commit and before all events have been dequeued. I'm not the fan of ThreadLocal but it's better than messing the business interfaces (ItemService) with non-related parameters. See this for spring related implementation.

I guess a final answer is not possible as it really depends on the details of your system, especially all the external services that get triggered by the events.