[JBoss Cache: Core Edition] - Re: BerkeleyDB Deadlock Exception from JBoss Cache Loader: B
by galder.zamarreno@jboss.com
"niuxuetao_fiserv" wrote : About the write-intensive stuff, yes, we will have a lot more calls to attach() than modifying the already cached Pojos.
Attaching a pojo is an expensive operation where the pojo is dissected and mapped to the cache, hence such operation should be used as less as possible. Detailed information on the process can be found in http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs...
If you're calling attach more often than modifying the Pojo directly, I'm not sure of the suitability of PojoCache in your case. It might even be more of a burden than using plain JBoss Cache. The point of a PojoCache is that you attach once and then you interact with the bean as normal, calling it's getters,setters...etc and when you're done with it, you detach it.
"niuxuetao_fiserv" wrote : 1. If I call attach() with a key and value that already exist in the cache, what will happen?
Hmmm, do you mean what happens when you attach a pojo under a fqn+key that already contains a pojo? In that case, the existing pojo is detached and the new one is reattached. Due to the reasons above, this is an expensive operation.
"niuxuetao_fiserv" wrote : 2. How do I use transaction in java code to explicitly begin and end a transaction?
| - DummyTransactionManager.getUserTransaction()?
| - or like describe in this page? http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs... which looks a pretty old doc?
|
Well, depends the environment in which you're in. If you're within an application server, you get a UserTransaction from JNDI or from an EJB context.
If you're outside of an application server, you should be using something like JBoss Transactions that allows setting up a transaction manager and getting a user transaction. You can find examples in their docu.
Finally, DummyTransactionManager does what it says on the tin. It's dummy, so it's not really a transaction manager, it's simply used as a mock for testing purpouses and hence you shouldn't be using it in conjunction with your production code.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240929#4240929
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240929
16 years, 9 months
[JBoss Cache: Core Edition] - Re: How does JBoss Cache perform with high (15-20) number of
by bela@jboss.com
"souravm" wrote : All together I've around 250x1000 such entities, which would be replicated across 20 nodes (in about 2-3 mins timeframe).
|
Do you mean that every node has to store 250MB of data ? By 'replicated' I infer total replication: everyone replicates to everybody else...
anonymous wrote :
| Now each entity being a size of 1 KB, we have provisioned for 250MB memory at each instance level (that means every node has all the state of the system). Given that I think with increase in number of instances in the cluster, the memory need would not increase.
|
OK, but then you're not using total replication, I assume 250MB is the total data distributed across the cluster ?
anonymous wrote :
| My concern is more with the CPU cycles which will go in marshaling/unmarshaling data. Given that every instance would receive data from all other (N-1) instances, the CPU cycles in marshaling the data would grow in all nodes in addition of more nodes in the cluster.
|
Yes. Note that ispan doesn't use java.io.serialization though, so this is pretty efficient. But, yes, it might still be a perf issue.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240924#4240924
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240924
16 years, 9 months