-
1. Re: Optimal Clustered Infinispan - Hibernate configuration for multiple apps deployed on a server (Shared CacheManager vs Shared Jgroups transport)
galder.zamarreno Sep 13, 2010 10:39 AM (in response to amitkapps)1 of 1 people found this helpfulRe Option 1: If you can't marshall Hibernate's CacheKey, that's quite likely cos Hibernate 3.5.x or higher is not available in its classloader classpath. You should check what weblogic reqs are in this area.
Re Option 2: This won't solve your problem in Option 1. Is just another way to deploy JGroups layer
I think it's a bit early for you to be making this decision. Normally, you decide to have the same JGroups layer or a different one depending on your deployment/runtime/performance requirements. IOW, if you wanna reduce the number of mcast address/ports to mantain, you use option 2. If each app is very different and you need to tweak JGroups in a different way depending on the app, then Option 1.
-
2. Re: Optimal Clustered Infinispan - Hibernate configuration for multiple apps deployed on a server (Shared CacheManager vs Shared Jgroups transport)
amitkapps Sep 13, 2010 12:00 PM (in response to galder.zamarreno)Option1: If i were to add the hibernate libraries also as part of the system classloader i would essentially force all applications to a particular version of Hibernate.
Option2: With option 2 I would keep the marshalling and hibernate libraries as part of the application package(ear/war) and only the JGroups component in the system class path. That way the transport could be shared across different applications on the app-server at the expense of each app creating its own Cache manager. I read in the Infinispan docs that Cache manager component was relatively heavy and sharing that was recommended, and my question then would be if the heaviness of the Cache manager was mainly based on the heaviness of the JGroups' transport layer or because of its own sub component etc. With the shared transport is it still that heavy? IF so what sub components are we talking about? Thread pools etc... and how bad is that to have multiple copies of those (We'd be looking at 5-10 copies of those on an app server coz I'll have those many differnt apps needing the clustered caching feature.)
I Understand that if applications have different transport requirements then it means a different JGroups layer for them and going with OPtions 2 i'm not restricted with that either - I can still have a different transport definitions (I do not use the same singleton name that I use for the other shared transport).
-
3. Re: Optimal Clustered Infinispan - Hibernate configuration for multiple apps deployed on a server (Shared CacheManager vs Shared Jgroups transport)
galder.zamarreno Sep 23, 2010 12:17 PM (in response to amitkapps)1 of 1 people found this helpfulOption 2: It's heavy cos you have a JGroups stack per cache manager, but the main issue is maintance of bind ports, multicast addresses...etc. 5-10 is prob too much. We used to have such set up in AS 4 and it was a nightmare to maintain. 2-3 would be top IMO.