Open s4ke opened 9 years ago
that way the updates don't need to be distributed in a backend. => no JMS/JGroups needed.
Selection whether we already did the update can be done via:
power := 2^your_id; your_id = 0,...,63
WHERE mod(handledField / power, 2) >= 1.0 AND mod(handledField / power, 2) < 2;
problem is that this might be quite bad performance wise.
org.hibernate.search.genericjpa.searchfactory.triggers.createstrategy=create is a must in such an environment. drop-create will break things, but if a user does a massindexing right after a new node starts, that would be fine. but that's just a bit much to ask. so we should clearly advertise "create" for this mode.
Another way would be having a special table for each node and then store the ids of all the updates we already have processed there. This would be less error prone than the bit flag approach, but would consume a bit more memory. (for N nodes on the same database you would have N extra tables). Query time for the updates would be impacted a little as well.
bit-flags for each server in the UpdateSource