|
View:
New views
3 Messages
—
Rating Filter:
Alert me
|
|
|
Cache Coordination issueI'm running EclipseLink with our JEE application and deploying to a GlassFish cluster. I've enabled Cache Coordination to keep the instances in sync utilizing a JMS Topic. Our application is an event driven model and utilizes JMS heavily. Each state change results in a message being produced on a Jms queue and a we have different MDB's to consume the messages based upon their state. I've run into a situation where a process (entity named process) was created on server 1, processing then resumed on server 2, and attempted to complete on server 1. state changes (PENDING, PROCESSING, APPROVED).
The issue that I ran into was processing began on server 1, migrated to server 2, and tried to complete on server 1 and but saw the process in a state of PENDING while the process was actually in a state of APPROVED. I know that the coordination is working between the two instances as I have tested this through the UI and have seen the updates occur. I've also seen the EclipseLink log messages pertaining to message consumption so I know that the updates are flowing between the two instances. So is this simply a case where the message that my application was processing got consumed prior to the coordination message that Eclipselink produced? I've since taken these objects out of the shared cache to prevent this issue from arising again. Is this my best strategy or is there something else that I am overlooking? Thanks for the help... |
|||||||||||
|
|
RE: Cache Coordination issueYou could send with your application message the expected version of
entity "process", then if version you see in new server is older, you refresh it first or idle a little giving time to the JMS based cache coordination to receive the update. It's all about synchronous or asynchronous propagation. JMS based cache coordination is normally asynchronous, so default behavior you see is normal. -----Original Message----- From: eclipselink-users-bounces@... [mailto:eclipselink-users-bounces@...] On Behalf Of cmathrusse Sent: Monday, July 06, 2009 8:44 PM To: eclipselink-users@... Subject: [eclipselink-users] Cache Coordination issue I'm running EclipseLink with our JEE application and deploying to a GlassFish cluster. I've enabled Cache Coordination to keep the instances in sync utilizing a JMS Topic. Our application is an event driven model and utilizes JMS heavily. Each state change results in a message being produced on a Jms queue and a we have different MDB's to consume the messages based upon their state. I've run into a situation where a process (entity named process) was created on server 1, processing then resumed on server 2, and attempted to complete on server 1. state changes (PENDING, PROCESSING, APPROVED). The issue that I ran into was processing began on server 1, migrated to server 2, and tried to complete on server 1 and but saw the process in a state of PENDING while the process was actually in a state of APPROVED. I know that the coordination is working between the two instances as I have tested this through the UI and have seen the updates occur. I've also seen the EclipseLink log messages pertaining to message consumption so I know that the updates are flowing between the two instances. So is this simply a case where the message that my application was processing got consumed prior to the coordination message that Eclipselink produced? I've since taken these objects out of the shared cache to prevent this issue from arising again. Is this my best strategy or is there something else that I am overlooking? Thanks for the help... -- View this message in context: http://www.nabble.com/Cache-Coordination-issue-tp24365342p24365342.html Sent from the EclipseLink - Users mailing list archive at Nabble.com. _______________________________________________ eclipselink-users mailing list eclipselink-users@... https://dev.eclipse.org/mailman/listinfo/eclipselink-users _______________________________________________ eclipselink-users mailing list eclipselink-users@... https://dev.eclipse.org/mailman/listinfo/eclipselink-users |
|||||||||||
|
|
RE: Cache Coordination issueThank you for the suggestion. I do in fact send the expected state of the entity and I did add the 'refresh' to the code in case the state was not as expected. It seemed like a small price to pay to ensure that the entities were kept in sync. I just wanted to ensure that I was not overlooking some other option. Seeing as the propagation is asynchronous I do understand that there is the potential for 'lag' time. There is no way to predict when a message will be consumed or in which order. It is all up to the messaging server. I do know that the JMS messages produced by EclipseLink should be participating in the global tx that is running and that any messages produced will not be sent until the tx has committed. This goes the same for the messages my application produces and there is no way to know which one will be consumed first, so I think that the refresh is a necessity. Thanks for the help... Chris Mathrusse christopher.mathrusse@... Sybase, Inc
You could send with your application message the expected version of entity "process", then if version you see in new server is older, you refresh it first or idle a little giving time to the JMS based cache coordination to receive the update. It's all about synchronous or asynchronous propagation. JMS based cache coordination is normally asynchronous, so default behavior you see is normal. -----Original Message----- From: eclipselink-users-bounces@... [mailto:eclipselink-users-bounces@...] On Behalf Of cmathrusse Sent: Monday, July 06, 2009 8:44 PM To: eclipselink-users@... Subject: [eclipselink-users] Cache Coordination issue I'm running EclipseLink with our JEE application and deploying to a GlassFish cluster. I've enabled Cache Coordination to keep the instances in sync utilizing a JMS Topic. Our application is an event driven model and utilizes JMS heavily. Each state change results in a message being produced on a Jms queue and a we have different MDB's to consume the messages based upon their state. I've run into a situation where a process (entity named process) was created on server 1, processing then resumed on server 2, and attempted to complete on server 1. state changes (PENDING, PROCESSING, APPROVED). The issue that I ran into was processing began on server 1, migrated to server 2, and tried to complete on server 1 and but saw the process in a state of PENDING while the process was actually in a state of APPROVED. I know that the coordination is working between the two instances as I have tested this through the UI and have seen the updates occur. I've also seen the EclipseLink log messages pertaining to message consumption so I know that the updates are flowing between the two instances. So is this simply a case where the message that my application was processing got consumed prior to the coordination message that Eclipselink produced? I've since taken these objects out of the shared cache to prevent this issue from arising again. Is this my best strategy or is there something else that I am overlooking? Thanks for the help... -- View this message in context: http://www.nabble.com/Cache-Coordination-issue-tp24365342p24365342.html Sent from the EclipseLink - Users mailing list archive at Nabble.com. _______________________________________________ eclipselink-users mailing list eclipselink-users@... https://dev.eclipse.org/mailman/listinfo/eclipselink-users _______________________________________________ eclipselink-users mailing list eclipselink-users@... https://dev.eclipse.org/mailman/listinfo/eclipselink-users _______________________________________________ eclipselink-users mailing list eclipselink-users@... https://dev.eclipse.org/mailman/listinfo/eclipselink-users |
| Free embeddable forum powered by Nabble | Forum Help |