This content has been marked as final. Show 2 replies
I would go with solution one: write a database publisher that is a peer to the remote cluster publisher.
At first glance I don't think you would have to worry about complicating conflict resolution since any
writes seen by the database publisher by definition would have been resolved by the CR solution
you wrote for publishing to another cluster. CR is done at the target site by the "local" batch
publisher using the "front door" into Coherence, so all entries that are artifacts of CR go through
the standard paths if CR decides to not to discard the entry coming from another cluster but
either retain the entry "as is" or merge it with the local entry value.
Anyway by the time a database publisher sees something to be published, CR has been done.
What is good about defining a database publisher is that it can have its own set of publishing
attributes tuned for publishing to a DB rather than a network. It also makes writing to the
DB asynchronous from writes to the cache.
I started out with option 1, but, it does not actually work with PRP.
The PRP event makes it across from Site A to Site B, but the Database publisher attached to Site B does not get fired. The only time the database publisher gets fired on site B, is if the event was generated in site B.
I wonder in your internal ping/pong logic (similiar concept you used to have with SafePublishingCacheStore) is stopping the entry being published to the Site B database publisher.
Anyhow I ended up going for option 3:
PRP event makes it across from Site A to Site B
Conflict resolution is run, and value is written to my cache.
A trigger which is attached to this cache fires, and I write to another cache (with high-units=0, so as not to take up extra cluster space), this then has a normal database cache store attached, seems to work well.