Eclipse Community Forums: EclipseLink » JMS Cache coordination

Home » Eclipse Projects » EclipseLink » JMS Cache coordination (Issue MDB message contains Command type object instead of RemoteCommand )

Show: Today's Messages :: Show Polls :: Message Navigator

JMS Cache coordination [message #1059565]

Mon, 20 May 2013 13:40

ELUser Mising name

Messages: 26
Registered: May 2013

Junior Member

We are trying to implement JMS Cache coordination in our application by using MDBs in a clustered Websphere Application Server environment.
When we update or insert an object we see that the MDB message includes an object of type MergeChangeSetCommand and not RemoteCommand.

We are trying the code below, but the object is not of the type RemoteCommand; Is that expected?
Can someone please guide us on the correct usage?
Thanks for the help.

public void onMessage(Message message)
{
try {
if(message instanceof ObjectMessage) {
ObjectMessage objectmessage = (ObjectMessage)message;
java.io.Serializable serializable = objectmessage.getObject();
if(serializable instanceof RemoteCommand) {
((RemoteCommand)serializable).execute((
AbstractSession)getSession(), null);
}
}
}

Report message to a moderator

Re: JMS Cache coordination [message #1059832 is a reply to message #1059565]

Tue, 21 May 2013 19:08

Chris Delahunt

Messages: 1389
Registered: July 2009

Senior Member

The design doc here http://wiki.eclipse.org/EclipseLink/Development/JMSCacheCoordinationUsingMDB intended to allow delegating everything to the JMSTopicRemoteConnection.onMessage() call. This method will get the object from the message if necessary, and check if it is an instance of (object instanceof Command) before executing it on the session. RCMCommand instances are relevant to the RemoteCommandManager itself, such as connection requests when using RMI/JNDI RCM strategies. MergeChangeSetCommand and MetadataRefreshCommand, which are direct Command subclasses, are aimed at the Session.

Report message to a moderator

Re: JMS Cache coordination [message #1060978 is a reply to message #1059832]

Wed, 29 May 2013 12:00

P Soma

Messages: 9
Registered: May 2013

Junior Member

We had implemented onMessage() method of MDB as below and NoteBO entity class has implemented to invalidate the cache on cache coordination in other server.

public void onMessage(final Message message) {
final String METHOD_NAME = "onMessage";
log.entering(CLASS_NAME, METHOD_NAME);
try {
if (message instanceof ObjectMessage) {
final Serializable object = ((ObjectMessage)message).getObject();
final AbstractSession session = getSession();
if (object instanceof MergeChangeSetCommand) {
final MergeChangeSetCommand command =
((MergeChangeSetCommand)object);
command.executeWithSession(session);
}
}
} catch (final Exception ex) {
this.messageDrivenContext.setRollbackOnly();
}
}

@Entity
@Table(name = "IJABA12_NOTE")
@Cache(type = CacheType.SOFT,
size = 64000,
expiry = 360000,
coordinationType = CacheCoordinationType.INVALIDATE_CHANGED_OBJECTS
)
public class NoteBO extends JabBaseBO implements Comparable<NoteBO> {
....
}

Also we have configured Server 1 & Server 2 to listen to the same JMS topic and added necessary properties in persistence.xml related to JMS cache coordination. So, whenever any changes on the entity in one server (e.g. Server 1) will be published as a JMS message and the other Server consume the message to invalidate the entity in the cache (e.g. in Server 2). But we have noticed that after executed the line command.executeWithSession(session), nothing has happened on the other server. Please, can someone help us to resolve this issue?

Report message to a moderator

Re: JMS Cache coordination [message #1061235 is a reply to message #1060978]

Thu, 30 May 2013 16:19

Chris Delahunt

Messages: 1389
Registered: July 2009

Senior Member

Can you describe what you mean by nothing happened a bit more? Invalidation doesn't change the entity, it only marks it as stale so that it can be refreshed when it is queried. This occurs on the shared cache, so any UnitOfWork or EntityManager that already has the instance read in will not be affected, since their copy is isolated from the shared cache, and any other entities referencing the stale object will still show potentially stale data until that object is refreshed. Could this be what you are seeing? Try using SEND_NEW_OBJECTS_WITH_CHANGES or SEND_OBJECT_CHANGES to see if that helps your situation.

Best Regards,
Chris

Report message to a moderator

Re: JMS Cache coordination [message #1061244 is a reply to message #1061235]

Thu, 30 May 2013 17:54

P Soma

Messages: 9
Registered: May 2013

Junior Member

What I meant that the object is not invalidated on the shared cache on Server 2. Hence if I tried to read the same object on Server 2 then the object has retrieved from the shared cache without reading it from database. The following sequence of steps will help you to better understand my issues.

1) Server 1 & Server 2 pointing/listening to the same JMS topic in Cluster environment.
2) Retrieved an Entity (i.e for Key-A) on Server 1
3) Update any value and then commit the changes on Server 1.
4) JMS message has sent with changes to JMS Topic on Server 1.
5) Server 2 process/consume the JMS message and invoke command.executeWithSession(session) method. -- Expected result the changed entity should be invalidated on the shared cache.
6) Retrived the same entity (i.e for Key-A) on Server 2. Returned the entity with old values. -- Expected entity with the changes.

Am I missing anything? For your reference I have attached some of the files for the above test case. Please help me to resolve this issue.

Thanks in Advance.

Attachment: JMS Cache Coordination.zip
(Size: 5.19KB, Downloaded 209 times)

Report message to a moderator

Re: JMS Cache coordination [message #1061253 is a reply to message #1061244]

Thu, 30 May 2013 19:01

Chris Delahunt

Messages: 1389
Registered: July 2009

Senior Member

I assume then you have debugged and that you are correctly seeing the "*******Successfully message has processed. *********" messages that indicate the command was processed. Does changing the CacheCoordinationType help or change anything? What is the nature of the change you are making, and do any other changes successfully invalidate the remote cache? How are you accessing the entity after the changes are received?

[Updated on: Thu, 30 May 2013 19:02]

Report message to a moderator

Re: JMS Cache coordination [message #1061255 is a reply to message #1061253]

Thu, 30 May 2013 19:13

P Soma

Messages: 9
Registered: May 2013

Junior Member

Yes I can see the "*******Successfully message has processed. *********" message after executed the command. But the object on the shared cache is not invalidated. As you suggested, I will try to change the CacheCoordinationType and then test and let you know.

Report message to a moderator

Re: JMS Cache coordination [message #1061673 is a reply to message #1061255]

Mon, 03 June 2013 12:53

P Soma

Messages: 9
Registered: May 2013

Junior Member

Hello,

As you suggested I have tried by changing the Coordination type to SEND_NEW_OBJECTS_WITH_CHANGES. Whenever I have updated any value in the NoteBO entity (i.e. for Key-A) on one server (i.e. Server1) and I can see the following messages when the JMS message has process on the another server (i.e. Server2) .

****************************************************************
[6/3/13 8:37:12:564 EDT] 00000120 SystemOut O [EL Finer]: propagation: 2013-06-03 08:37:12.564--UnitOfWork(428113568)--Thread(Thread[SIBJMSRAThreadPool : 0,5,main])--Received updates from Remote Server

[6/3/13 8:37:12:565 EDT] 00000120 SystemOut O *******Successfully message has processed. *********
****************************************************************

After that I had tried to retrieve the entity for the same key (i.e. Key-A) on the 2nd server (i.e. Server2) but the entity has returned with stale value from the cache (expected the new value which has been updated on server1). This has confirmed that after execution of command.executeWithSession(session) method on server2 is never updated in the shared cache with the new values on the entity for Key-A.

Please let us know what could be the reason and how to resolve this issue.

Report message to a moderator

Re: JMS Cache coordination [message #1061686 is a reply to message #1061673]

Mon, 03 June 2013 13:38

Chris Delahunt

Messages: 1389
Registered: July 2009

Senior Member

How are you verifying that the data is stale? Be sure that you are not using a UnitOfWork or EntityManager that might already have the entity in question preloaded with the stale data.

Can you try debugging what is in the command - It should be a MergeChangeSetCommand instance and getChangeSet(session) should return a UnitOfWorkChangeSet instance representing the changes in the remote transaction.

Report message to a moderator

Re: JMS Cache coordination [message #1061695 is a reply to message #1061686]

Mon, 03 June 2013 14:06

P Soma

Messages: 9
Registered: May 2013

Junior Member

I am executing the following steps to verify cache coordiantion.

Step 1 : Execute the following steps on Server 2:

final NoteBO note = entityManager.find(NoteBO.class, key);
System.out.println("Desciption " + note.getNote());

Step 2 : Execute the following steps on Server1:

final NoteBO note = entityManager.find(NoteBO.class, key);
System.out.println("Old Desciption " + note.getNote());
final Random rand = new Random();
note.setNote("Test (" + rand.nextInt(100) + ") - ");
entityManager.getTransaction().begin();
entityManager.merge(note);
entityManager.getTransaction().commit();

After the enity has committed on server1, eclipselink has sent a JMS message with the changes.

Step 3 : Execute the following steps after JMS message has processed on Server 2:

final NoteBO note = entityManager.find(NoteBO.class, key);
System.out.println("Desciption " + note.getNote());

In Step 3, I can see the same old description value (i.e. same as in Step 1) of Note entity. When I debugged, I found that the following line is always returing null value within MergeManager.mergeChangesFromChangeSet(UnitOfWorkChangeSet) method.

Object object = objectChangeSet.getTargetVersionOfSourceObject(this, this.session, false);
if (object != null) {
mergeChanges(object, objectChangeSet, this.session);
.....

That's why mergeChanges method has never invoked. Is there anything, I am doing wrong?

Report message to a moderator

Re: JMS Cache coordination [message #1061756 is a reply to message #1061695]

Mon, 03 June 2013 19:01

Chris Delahunt

Messages: 1389
Registered: July 2009

Senior Member

objectChangeSet.getTargetVersionOfSourceObject(this, this.session, false) attempts to get the object from the cache. If it is returning null, then there is nothing to merge into. Is your Server 2 operating within a transaction when it is performing find in step 1? Try clearing the EntityManager using em.clear() before attempting the find in step 3 - it should go to the shared cache or database for the entity.

Report message to a moderator

Previous Topic:	When a merge does not update?
Next Topic:	EclipseLink DBWS with JPQL

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Apr 16 18:04:13 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter