JMS caching vs. ehcache

Hi everyone.
I have a simple question: Is JMS suitable for data caching and how is it used? Which one should I use JMS caching or some 3rd party caching system like ehcache?
Thank you. Appreciate your help!

Simple answer - No - JMS is not suitable for data caching.

Similar Messages

10.1.3 JMS Cache Synchronization on OC4J

Hi,
We're using stand-alone OC4j 10.1.3.0 along with TopLink 10.1.3.0 (packaged with OC4j). In enabling JMS cache synchronization, I get the following error message:
Exception [TOPLINK-12000] (Oracle TopLink - 10g Release 3 (10.1.3.0.0) (Build 060118)): oracle.toplink.exceptions.CommunicationException
Exception Description: Error Sending connection service to jms/Topic/ToplinkCacheSync.
Internal Exception: javax.jms.JMSException: TopicSubscriber[Oc4jJMS.Consumer.arkansas.6e2ec2b0:1117159d1ca:-7fff.65,Topic[ToplinkCacheSync],null,null,false]: cannot invoke method "setMessageListener" within the J2EE container.
at oracle.toplink.exceptions.CommunicationException.errorSendingConnectionService(CommunicationException.java:40)
at oracle.toplink.remote.CacheSynchronizationManager.addRemoteConnection(CacheSynchronizationManager.java:175)
at oracle.toplink.remote.jms.JMSClusteringService.retreiveRemoteSessions(JMSClusteringService.java:198)
at oracle.toplink.remote.jms.JMSClusteringService.run(JMSClusteringService.java:175)
Caused by: javax.jms.JMSException: TopicSubscriber[Oc4jJMS.Consumer.arkansas.6e2ec2b0:1117159d1ca:-7fff.65,Topic[ToplinkCacheSync],null,null,false]: cannot invoke method "setMessageListener" within the J2EE container.
at com.evermind.server.jms.JMSUtils.make(JMSUtils.java:1034)
at com.evermind.server.jms.JMSUtils.toJMSException(JMSUtils.java:1114)
at com.evermind.server.jms.JMSUtils.toJMSException(JMSUtils.java:1085)
at com.evermind.server.jms.JMSUtils.assertNotContainer(JMSUtils.java:1500)
at com.evermind.server.jms.EvermindMessageConsumer.setMessageListener(EvermindMessageConsumer.java:217)
at oracle.toplink.remote.jms.JMSClusteringService.connectBackToRemote(JMSClusteringService.java:53)
at oracle.toplink.remote.CacheSynchronizationManager.addRemoteConnection(CacheSynchronizationManager.java:168)
... 2 more
It is, therefore, my assumption that Toplink is using JMS 1.0.2b while OC4J is using JMS 1.1. Who can:
1) Verify or debunk my assumption?
2) Point me to a work-around?
Perhaps my config is incorrect? Here's a sessions.xml snippet, in case it helps:
<cache-synchronization-manager>
<clustering-service xsi:type="jms-clustering">
<naming-service-url>ormi://localhost:23791/ems</naming-service-url>
<jndi-user-name>oc4jadmin</jndi-user-name>
<jndi-password>oc4j</jndi-password>
<naming-service-initial-context-factory-name>com.evermind.server.rmi.RMIInitialContextFactory</naming-service-initial-context-factory-name>
<jms-topic-connection-factory-name>jms/Topic/ToplinkCacheSyncConnectionFactory</jms-topic-connection-factory-name>
<jms-topic-name>jms/Topic/ToplinkCacheSync</jms-topic-name>
</clustering-service>
<remove-connection-on-error>false</remove-connection-on-error>
</cache-synchronization-manager>
Many thanks in advance,
--Todd

Thank you very much for your contribution! Yes, indeed, that was my main issue. A sessions.xml section that looks like the following (instead of the <cache-synchronization-manager> section above) does fix the problem:
<remote-command>
<commands>
<cache-sync>true</cache-sync>
</commands>
<transport xsi:type="jms-topic-transport">
<topic-host-url>ormi://localhost:23791/ems</topic-host-url>
<topic-connection-factory-name>jms/Topic/ToplinkCacheSyncConnectionFactory</topic-connection-factory-name>
<topic-name>jms/Topic/ToplinkCacheSync</topic-name>
<jndi-naming-service>
<user-name>oc4jadmin</user-name>
<password>oc4j</password>
<initial-context-factory-name>com.evermind.server.rmi.RMIInitialContextFactory</initial-context-factory-name>
</jndi-naming-service>
</transport>
</remote-command>
Thanks again,
--Todd

JMS Cache Synchronization Manager

Hi all,
I am trying to implement distributed cache synchronization in TopLink using JMS.
On http://download-west.oracle.com/docs/cd/A97688_12/toplink.903/b10064/enterpri.htm#1022254 , there is an example given which has a snippet of the sessions.xml file.
The example snippet shows a tag <naming-service-initial-context-factory> under the <cache-synchronization-manager> tag. But on the DTD given on http://download-west.oracle.com/docs/cd/A97688_12/toplink.903/b10064/a-sessio.htm#634251 , I cant find an element <naming-service-initial-context-factory>. Please let me know which one is wrong - the DTD or the example?
Also, I tried to use JMS for distributed cache synchronization. My JMS Server is running on a seperate VM and I have configured info about it in the sessions.xml file. But TopLink is complaining that it cannot find the top and connection factory. Yet, I am able to look them up from a standalone program.
Does anyone have any experience setting this up? Any examples?
Thanks,
Binil

Hi Doug,
Thanks for the clarifications! :)
I am not able to get the JMS Cache Synchronization work still :( I am new to JMS & Toplink - so I will try to explain what I am doing and please let me know if there is something I am doing wrong.
I have an EJB application which is a Stateless Session bean which has two methods : one to fetch an entity and another to update an entity. Also, I have a weblogic domain in which I have three managed servers - appServerOne, appServerTwo and jmsServer. On appServerOne and appServerTwo I have deployed the above mentioined application. On jmsServer, I have configured my ConnectionFactory and Topic and the JNDI names of those are provided to the EJB application.
With this setup, I run two client programs. I will list the steps below:
1. Client1 fetches an entity whereby it is loaded to the TopLink cache. The DB logs show that a SELECT query is issued to the DB.
2. Client2 fetches the same entity whereby it is loaded to the cache; again a SELECT query is issued.
3. Client1 updates that entity using UOW; the logs dont show a DB UPDATE statement though. But the updates are indeed made to the DB when I check them.
4. Client1 fetches the entity again; the updates are visible and the JDBC logs show that a trip to the DB is not done.
5. After waiting for sometime Client1 fetches the same entity again and I get the stale data! :(
I have enabled logging, so I am hoping that TopLink will log a message when a JMS notification is posted. Also, I have made the cache synchronization synchronous, so that the transaction shouldnt commit before the notification being send.
I tried making the stateless session bean stateful and it still didnt work. Is there anything I need to do.
Cheerio,
Binil

JMS Cache Synchronization - Merge or Database Read?

When an object in one JVM is changed does TopLink' JMS cache synchronization mechanism merge the changes into the other JVMS in a cluster or does it just signal that the object is dirty and the object is re-read from the database?
If the answer is 'merge' does a post merge event get called on the object being merged?
thanks
Steve

In TopLink 10.1.3 both can happen, the changes can be merged or an object can be marked invalid and TopLink will refresh the object as needed. In 9.0.4.X the changes will be merged into the other caches (if an object of correct version exists in that cache).
In the case of a merge postMerge() event will be called.
--Gordon

Memory leak when using JMS Cache Coordination

We have two Weblogic Server 8.1 processes running Java 1.4.2 on Solaris using TOPLink 10.1.3 with JMS Cache Coordination. We observe that heap is filled with uncollectable instances of TOPLink-mapped classes. In our production system, under full load, this completely fills a 3.6 GB heap in 30 minutes, requiring a process restart. The problem goes away if we turn off cache coordination.
It appears that these instances are UnitOfWork or some other kind of toplink-created clone. We have not yet been able to successfully analyse this problem with a heap profiler.
Has anyone else experienced this this problem? Any suggestions for debugging?
Thanks in advance.

We do set the command manager to asychronous mode. (Our debug tracing confirms that the CommandPropagator method asynchronousPropagateCommand() is invoked, not synchronousPropagateCommand().) We started with asynchronous messaging and actually have never tried running in a synchronous mode.
The Java bug I referenced in my last post (which I have confirmed with a stand-alone test case) indicates that, for Java 1.4.2 and earlier, is is never ok to not start() a Thread -- it will always produce a memory leak. So I am quite surprised than anyone on a pre-1.5 Java had ever had success with synchronous cache coordination messaging. Do you think it is possible all of the pre-release tests and existing customers installations of 10.1.3 cache coordination are using Java 1.5 ?!
Our heap profiling indicates that the instances of CommandPropagator which are pinned (i.e., those not started) are allocated in the run() method of CommandPropagator itself. So it seems that the instance of CommandPropagator, after it is started, allocates another one in its run method. Looking at the bytecodes for the run() method (using javap -c) shows that in one branch of the code a second CommandPropagator is indeed allocated and then handed off to the launchContainerRunnable method of a ServerPlatform.
Since these secondary CommandPropagators are the ones which are not started, we have looked into the WebLogic_8_1_Platform class and found that its implementation launchContainerRunnable (inherited from ServerPlatformBase) does a
new Thread(runnable).start()where the argument runnable is the CommandPropagator.
So the CommandPropagator itself is not started(), but is instead run an another Thread.
We are experimenting with a custom ServerPlatform which overrides launchContainerRunnable:
    server.setServerPlatform(
        new WebLogic_8_1_Platform(server)
            public void launchContainerRunnable(Runnable runnable)
               if (runnable instanceof Thread) ((Thread)runnable).start();
               else super.launchContainerRunnable(runnable);
    ); This starts the argument Runnable directly if it is actually a Thread. Our early, small-scale tests indicate that this change eliminates the memory leak. We are testing now in a production-replicate environment under full load.
But this feels like a hack. I have no idea what TOPLink behavior other than cache coordination flows through this method. Does anyone know what else this ServerPlatform method is used for? Is there a better way to do this? Are there any adverse conquences to our hack? Any suggestions would be appreciated.
Thanks in advance.

JMS Cache Sync Problems

All,
We're running into some strange problems synchronizing Toplink caches via JMS.
In our environment, we have two different applications running under the same app server - different code in general, but they use the same Toplink mapping and mapped classes. Each of these connects to the database independently of the other using Toplink. We've configured sessions.xml to keep the caches between the two synchronized.
Now when an object is updated on one side or the other, the message gets sent out across JMS. However, when both applications read the message back in, we get strange errors like this one:
ServerSession(1204462)--Thread[PointcastTopicConnection,5,main]--EXCEPTION [TOPLINK-10000] (TopLink - 9.0.3.5 (Build 436)): oracle.toplink.exceptions.JMSProcessingException
EXCEPTION DESCRIPTION: (There is no English translation for this exception.)
INTERNAL EXCEPTION: javax.jms.MessageFormatException: Unable to deserialize object: java.lang.ClassCastException: Assigning instance of class oracle.toplink.internal.sessions.ObjectChangeSet to field oracle.toplink.internal.sessions.ObjectReferenceChangeRecord#newValue
Has anyone seen something like this before? We're using Toplink 9.0.3.5 with OC4J 9.0.2.2 (build 021224.1834).
(Apologies if this isn't Toplink-related. It's hard to tell if this is the App Server or Toplink failing here)
Thanks
- Don

I found this on http://download.oracle.com/docs/cd/B10464_05/web.904/b10313/cache.htm
Note:
When you select JMS as the transport mechanism in the clustering-service element, OracleAS TopLink ignores the discovery setting.
Does ignoring the discovery setting mean that it is not used?
Thanks.

JMS Cache Sync - is multicast used for

I wanted to verify whether or not the JMS clustering service was using mutlicast for initial discovery of other cache instances in the cluster environment or not.
Thanks for any assistance.

I found this on http://download.oracle.com/docs/cd/B10464_05/web.904/b10313/cache.htm
Note:
When you select JMS as the transport mechanism in the clustering-service element, OracleAS TopLink ignores the discovery setting.
Does ignoring the discovery setting mean that it is not used?
Thanks.

JMS Cache updates in existing transactions

We have two application instances running, with synchronization over JMS. In the following scenario what will be the outome?
- AppInstance1 does changes to Object1 and commits. These changes are sent to the JMS queue.
- AppInstance2 is in the middle of one transaction when it recieves the cache updates. The current transaction include Object1 (which updates are received for).
Does the transaction in Instance2 get aborted upon receiving the cache sync or are the mechanisms at work in TopLink smart enough to merge the non conflicting fields?
Thanks,
Anders,

This depends on your locking mechanism and has little to do with cache-synch. Cache synchronization does not replace the requirement for a locking mechanism.
If you are using no locking, then no matter if you have a single server, multiple servers with or without cache synch, then there is the potential that concurrent transactions can overwrite each others data.
If you are using optimistic locking, then no matter if you have a single server, multiple servers with or without cache synch, your second transaction will get an optimistic lock error and its transaction will be rolled-back.
If you are using pessimistic locking, then there is not much point in using cache synch as you will be accessing the database anyway. The second transaction will block on its read of the object until the first transaction completes, or throw an error on read if using no_wait.
The benefit that cache synchronization provides it that because changes are synchronized between servers the likely-hood of getting an optimistic lock exception is greatly reduced. It can also be used with infrequently updated objects that do not use any locking, or object to which locking is not an issue.

JMS & Cache synchronization

We have setup Toplink to do cache synchronization using Tibco JMS. We are using Tomcat Servlet environment. We are using the pre-login event in Toplink to specify the necessary information required for cache synchronization using JMS. For some reason Toplink connects to JMS using the name "anonymous" in addition to connecting with the user name we specify in the code. Toplink also seems to connect to some queue in addition to the Topic that is mentioned in the code. Does anyone know why Toplink would behave like this?

Hello,
TopLink uses JNDI to get the TopicConnectionFactory, and will login using the username/password you have specified. It then calls createTopicConnection() that will use the default userid to get a connection to a Topic, so this could be what you are referring to. The login specified in the cache synch setup is only to access JNDI.
That said, TopLink does not use a queue that I have ever seen. The source code for the JMSClusteringService is shipped with TopLink and can be used to fill in parts left out of the documentation, as well as allow for customizations. In this case, it would be good to review it to get an understanding of the calls TopLink does to connect. If this does not help, I'd need to see the configuration used to set up cache synchronization.
Best Regards,
Chris Delahunt

Class not found with jms cache sync

hi. when i try to use the remote command manager in my live environment only i get a class not found exception for my initial context factory. using a debugger i discovered this is actually hiding a linkage error. so i confirmed that my resin and java versions and all my jars are the same between live and stage, where this works no problem. but still doesn't work in production. any ideas what else i should look at? here's a stack trace
Exception [TOPLINK-22101] (Oracle TopLink - 10g Release 3 (10.1.3.1.0) (Build 061004)): oracle.toplink.exceptions.RemoteCommandManagerException
Exception Description: Could not obtain JNDI context with properties {java.naming.provider.url=tcp://10.10.6.73:3035, java.naming.factory.initial=org.exolab.jms.jndi.InitialContextFactory , java.naming.security.principal=tcp://10.10.6.73:3035, dedicated.connection=true, java.naming.security.credentials=tcp://10.10.6.73:3035}
Internal Exception: javax.naming.NoInitialContextException: Cannot instantiate class: org.exolab.jms.jndi.InitialContextFactory [Root exception is java.lang.ClassNotFoundException: org.exolab.jms.jndi.InitialContextFactory ]
at oracle.toplink.exceptions.RemoteCommandManagerException.errorObtainingContext(RemoteCommandManagerException.java:42)
at oracle.toplink.remotecommand.TransportManager.getContext(TransportManager.java:194)
at oracle.toplink.remotecommand.TransportManager.getRemoteHostContext(TransportManager.java:385)
at oracle.toplink.remotecommand.jms.JMSTopicTransportManager.getRemoteHostContext(JMSTopicTransportManager.java:270)
at oracle.toplink.remotecommand.jms.JMSTopicTransportManager.getTopicConnectionFactory(JMSTopicTransportManager.java:204)
at oracle.toplink.remotecommand.jms.JMSTopicTransportManager.createJMSTopicRemoteConnection(JMSTopicTransportManager.java:84)
at oracle.toplink.remotecommand.jms.JMSTopicTransportManager.createLocalConnection(JMSTopicTransportManager.java:106)
at oracle.toplink.remotecommand.jms.JMSTopicDiscoveryManager.startDiscovery(JMSTopicDiscoveryManager.java:44)
at oracle.toplink.remotecommand.RemoteCommandManager.initialize(RemoteCommandManager.java:132)
at oracle.toplink.publicinterface.DatabaseSession.login(DatabaseSession.java:509)

I would guess the problem is related to the application's class-loader visibility. Verify that your application can access the class org.exolab.jms.jndi.InitialContextFactory forio to launching the TopLink session. If it cannot then you may need to address the container's access to this library.
Doug

JMS Exception during cache synchronization

Hi,
I am using JMS cache synchronization fro two applications . During cache synchronization I got this exception
Local Exception Stack:
Exception [TOPLINK-0] (OracleAS TopLink - 10g (9.0.4.5) (Build 040930)): oracle.toplink.exceptions.CommunicationException
Exception Description: javax.jms.JMSException: enqMessage at oracle.toplink.remote.jms.JMSConnection.processCommand(JMSConnection.java:54) at oracle.toplink.internal.remote.ChangeSetPropagator$1.run(ChangeSetPropagator.java:64)
Has this something to do with the message size ?
Appreciate any help.
Thanks
Priya

would not expect TopLink to connect twice at all. Is it possible that another service from within the ApplicationServer is connecting? I would recommend changing the JNDI location or the service port of the TIBCO JMS service and altering the TopLink JMS Clustering Service URL to reflect this change. Then verify that multiple connections are still being acquired.
--Gordon

Cache Sync with RCM using RMI

I am trying to do a cache synchronization between 2 nodes using RCM and RMITransportManager. The problem is my setup does not have a multicast server as mentioned in toplink documentation.
Can I do the cache synchronization using RMI ( through RCM) without a multicast server. I am using the Toplink 10.1.3 version.
Thanks
sk

Have you tried RMI, what error are you getting?
You could also try using JMS cache coordination.

Cache propagation exception

Hi,
We have a series of batch components that initialize toplink session, make some data reads/writes and then destroy that session. We noticed that when the session is in the process of being shut down right after it committed some changes to the database, we receive the exception below. Our theory is that the cache synchronization mechanism that is running in a separate thread simply does not have enough time to finish its job when it gets interrupted by the VM shutdown. The way we inclined to remedy this and make sure all database changes that are made by this toplink session get properly propagated is to put a 3-5 second delay before SessionManager.getManager().destroySession is called, but I was wondering if this issue is a know one, and has a cleaner solution.
We use toplink 9.0.4.5 with JMS cache synchronization mechanism configured.
Thanks,
Roman
UnitOfWork(6879888)--end unit of work commit
UnitOfWork(6879888)--release unit of work
ServerSession(33459432)--Exception [TOPLINK-0] (OracleAS TopLink - 10g (9.0.4.5) (Build 040930)): oracle.toplink.exceptions.CommunicationException
Exception Description: javax.jms.IllegalStateException: Producer is closedLocal Exception Stack:
Exception [TOPLINK-0] (OracleAS TopLink - 10g (9.0.4.5) (Build 040930)): oracle.toplink.exceptions.CommunicationException
Exception Description: javax.jms.IllegalStateException: Producer is closed
at oracle.toplink.remote.jms.JMSConnection.processCommand(JMSConnection.java:54)
at oracle.toplink.internal.remote.ChangeSetPropagator$1.run(ChangeSetPropagator.java:64)
ServerSession(33459432)--Connection(13948523)--disconnect
ServerSession(33459432)--failed_to_propogate_to (There is no English translation for this message.)
ServerSession(33459432)--initialize identitymaps
ServerSession(33459432)--Connection(13948523)--disconnect
ServerSession(33459432)--Connection(27766975)--disconnect
ServerSession(33459432)--Connection(2102960)--disconnect
ServerSession(33459432)--Connection(30587319)--disconnect
ServerSession(33459432)--Connection(12954112)--disconnect
ServerSession(33459432)--Connection(11681042)--disconnect
ServerSession(33459432)--Connection(27003862)--disconnect
ServerSession(33459432)--Connection(10668)--disconnect
ServerSession(33459432)--Connection(16954038)--disconnect
ServerSession(33459432)--Connection(31561261)--disconnect
ServerSession(33459432)--Connection(14898956)--disconnect
ServerSession(33459432)--Connection(26373776)--disconnect

In order for cache coordination to function properly the sessions involved must have the same name, set of persistent objects with identical descriptors and mappings.
The change sets are built based on the descriptors and mappings in the source node and the complete set of object's descriptors and mappings involved in the change must be available in the target node.
Doug

UnitOfWork.refreshObject(); don't fire event for Cache Synchronization

My WebApp use JMS for cache synchronization.
and I need to refresh session Cache by using method unitOfWork.refreshObject() but it don't publish any message to JMSserver.
sinse My JMS cache synchronization work well when I do UnitOfWok transaction(insert,update,delete)
How to force cache synchronization ?
thank you,
Kowit Laison

TopLink cache synchronization only synchronizes changes made through a unit of work, it does not synchronize reads or refreshes.
You will need to perform the refresh on each server, or make your own JMS message to notify your other server's to refresh.
You may also wish to investigate the TopLink 10.1.3 Preview release that adds support for Cache Invalidation and Cache Invalidation Synchronization. You may be able to broadcast an invalidation command for the refresh.

Caching modes and details in repository

hi all,
can any one please explain what is the uses of caching modes in repository ?elaborate it.
Thanks
Regards,
Shya

Hi Shya,
First, there are two types of cache for each item descriptor:
[1].*Item Caches*:Item caches hold the values of repository items, indexed by repository IDs. An item cache entry is invalidated when that item is updated.
[2].*Query Caches*:Query caches hold the repository IDs of items that match given queries. When a query returns repository
items whose item descriptor enables query caching, the result set is cached as follows:
--The query cache stores the repository IDs.
--The item cache stores the corresponding repository items.
Cache Modes:For example possible values are:
we can set <item-descriptor name="xyz" cache-mode="simple/disabled/inherit/locked/distributed/distributedJMS/distributedHybrid">....
simple caching handles caches in each server/VM locally; no attempt is made to synchronize updates across multiple server instances.
disabled is used when you dont want any caching on your repository and want your application to pick data everytime from your repository, like inventory to insure that inventory data is always up to date across server instances.
inherit is used when our item-descriptor have any super item-descriptor [as per concept of item descriptor inheritance], in this case our item descriptriptor use the cache mode of super item-descriptor.
-RMishra
locked caching uses read and write locks to synchronize access to items stored by multiple caches, so that only one VM should update cache at a time.
( distributed )Distributed TCP caching uses TCP to broadcast cache invalidation events (cache invalidation event means event to update cache data) to all servers in a cluster(group of servers).
( distributedJMS )Distributed JMS caching uses JMS to broadcast cache invalidation events to all servers in a cluster.
( distributedHybrid )Distributed hybrid caching uses TCP to send cache invalidation events only to those servers that are known to cache the target items. Hense all server's cache data of item-descriptor not going to update.
Note: Item descriptors within an inheritance tree share the same item cache. Queries that include derived item properties are never cached. Default caching mode is simple.

JMS caching vs. ehcache

Similar Messages

Maybe you are looking for