How can portlets listen to Database events ?

[Siby Mathew, modificado hace 11 años.]

Hi all,

My current setup :
- Multiple nodes share the same database updating the values.
- The cache is NOT shared among them

Requirement :
The liferay cache needs to be updated when any one node does a DB update.

Question
Is there a way portlets can listen to my database and update its cache .
Is cache independency a correct approach ? (I dont have control over this decision)
If we do proper clustering, can we shut down a node independent of the other. Will liferay handle this automatically ?

Thanks,
Siby

[David H Nebinger, modificado hace 11 años.]

Siby Mathew:

Is there a way portlets can listen to my database and update its cache

No. If you did, say, a model listener you can intercept a pending update to the DB, but that only works on an instance that is local to the machine in the cluster, but that machine would have already updated it's cache. You could not intercept a pending update for a different machine in the cache.

Is cache independency a correct approach ? (I dont have control over this decision)

No, and this is the true source of your problem. If you have a clustered Liferay setup, then the index must also be clustered, period.

If we do proper clustering, can we shut down a node independent of the other. Will liferay handle this automatically ?

Liferay is not managing the cluster, it just lives within the cluster. So yes, shutting down a node will be handled, but there is nothing specific within Liferay that must 'handle' the removal of the node.

[Siby Mathew, modificado hace 11 años.]

Hi David,
Thanks for your reply.
Please correct me If I am wrong, do you mean in Liferay, update happens like this:
Update call --> Cache update --> Model Listener --> DB update

And during the Model Listener execution, the 2nd node dont have the updated cache.
Is that what you mean ?

Thanks,
Siby

[David H Nebinger, modificado hace 11 años.]

Well, I think it's actually update call -> model listener -> db update -> cache update, but the order is maintained by the Liferay code and therefore out of your control.

The issue is that it is localized to the node of the cluster where it occurs. So if you have two nodes and user triggers the update on node A, the flow on the two nodes is:

A: update call -> model listener -> db update -> cache update
B: <nothing>

The update call starts on the node where the user did it. That update is entirely local on the node, the event is not replicated across the cluster.

That's why your request is just not possible. The other nodes have no visibility on what activity is going on in node A. In a proper cluster setup, the cache is a clustered cache so it's up to the cache implementation to replicate the update to the other nodes.

You have independent caches (so no replication), and an update to node A will never be broadcast to the other nodes.

Note that Liferay is not doing anything with respect to being in a cluster. Node A just calls it's designated cache implementation to update the cache w/ a new value. It's the clustered cache implementation that knows it's working in a cluster and takes care of the replication.

Liferay really plays no part in actively managing cluster information.

[Siby Mathew, modificado hace 11 años.]

Thanks for your answer David...
Even I am concerned about the data integrity if the cache is not shared.
Can you please give me details on which properties would enable cache-clustering in liferay.

Update: If the same user is logged-in from 2 server instances in same browser, one user gets logged out. Can anybody explain why ?

Thanks,
Siby

[David H Nebinger, modificado hace 11 años.]

Siby Mathew:

Can you please give me details on which properties would enable cache-clustering in liferay.

This is basically enabled in the portal-ext.properties file. I think there may be enough doco in portal.properties to explain what you need to do. You might want to also do a google search since you're not the first person to use it.

If the same user is logged-in from 2 server instances in same browser, one user gets logged out. Can anybody explain why ?

There is also another property in portal-ext.properties which can limit the number of times a single user can be logged into the portal. Have you determined if this is set?

[Atul Patel, modificado hace 11 años.]

If you configure Liferay clustering it will handle keeping the caches.

Last time I checked, it worked like this: update on Server A occurs, committed to db, cache is updated, if clustering is on, notify clustered nodes of update.

[David H Nebinger, modificado hace 11 años.]

Atul Patel:

If you configure Liferay clustering it will handle keeping the caches.

Last time I checked, it worked like this: update on Server A occurs, committed to db, cache is updated, if clustering is on, notify clustered nodes of update.

But, if you had read the original post, the user is not using clustered indexes, hence no cluster node notification, ...

[Atul Patel, modificado hace 11 años.]

Understood. The last line of his original post started off with "If we do proper clustering..." which is why I'm explaining how clustering might solve what he is trying to do.

PS. How are you David? Ping me on skype (atul.ducati) sometime. I'd love to get your input on an idea I have.

[Siby Mathew, modificado hace 11 años.]

Thanks for your answer Atul... Can you please answer this as well :

Thanks for your answer David...
Even I am concerned about the data integrity if the cache is not shared.
Can you please give me details on which properties would enable cache-clustering in liferay.

Update: If the same user is logged-in from 2 server instances in same browser, one user gets logged out. Can anybody explain why ?

Thanks,
Siby