Expand my Community achievements bar.

SOLVED

question about clustering configuration in LCDS3.1

Avatar

Level 2

In the LCDS3.1 doc, it's said "Using the
shared-backend="false"
configuration attribute does not guarantee a single consistent view of the data across the cluster
. When two clients are connected to different servers in the cluster, if they perform conflicting updates to the same data value, each server applies these changes in a different order. The result is that clients connected to one server see one view of the data, while clients connected to other servers see a different view. The conflict detection mechanism does not detect these changes as conflicts. If you require a single consistent view of data where two clients are updating the same data values at roughly the same time, use a database or other mechanism to ensure that the proper locking is performed when updating data in the back-end system."

Does it mean using the shared-backend = "true" DOES guarantee a single consistent view of the data across the cluster? Or it means I have to use database level locking in either case?

1 Accepted Solution

Avatar

Correct answer by
Level 3

Here's some info regarding this from Mete Atamel, engineer on the LiveCycle Data Services team:

When shared-backend=true, a single consistent view of data is guaranteed but this is not due to the shared-backend property itself but rather the fact that when shared-backend=true, there's a single DB used by multiple instances of LCDS.

Imagine the scenario where you have two LCDS nodes in a cluster with two data management destinations, one on node1, and one on node2, and they are clustered (via JGroups). You can have those destinations maintain their own DB, and when a change happens in one node¹s destination, the other node's destination gets a JGroups message and updates its own DB. This works but it's not ideal because at a given time, you¹re trying to maintain the same cluster state on two different DBs and there are times when the connected clients do not get consistent view of the data.

Instead, you can use a single DB and have the two destinations talk to the same DB, so you have a single consistent view of the data. When this is possible, you enable shared-backend property in LCDS destinations, that way when one destination updates the DB, and sends a JGroups message to the other destination, the other destination does not  try to update the DB again, instead it simply passes the update message back to the connected clients without sending it to the adapter.

View solution in original post

2 Replies

Avatar

Correct answer by
Level 3

Here's some info regarding this from Mete Atamel, engineer on the LiveCycle Data Services team:

When shared-backend=true, a single consistent view of data is guaranteed but this is not due to the shared-backend property itself but rather the fact that when shared-backend=true, there's a single DB used by multiple instances of LCDS.

Imagine the scenario where you have two LCDS nodes in a cluster with two data management destinations, one on node1, and one on node2, and they are clustered (via JGroups). You can have those destinations maintain their own DB, and when a change happens in one node¹s destination, the other node's destination gets a JGroups message and updates its own DB. This works but it's not ideal because at a given time, you¹re trying to maintain the same cluster state on two different DBs and there are times when the connected clients do not get consistent view of the data.

Instead, you can use a single DB and have the two destinations talk to the same DB, so you have a single consistent view of the data. When this is possible, you enable shared-backend property in LCDS destinations, that way when one destination updates the DB, and sends a JGroups message to the other destination, the other destination does not  try to update the DB again, instead it simply passes the update message back to the connected clients without sending it to the adapter.

Avatar

Level 2

very clear, I got it now, thanks a lot.