Hi
The differences are that approach 1 treats C as a store of data. Approach 2
treats C as a peer.
Even with approach 1, data changes in C will be picked up by B if the node
didn't already exist in B or if the node was evicted. So if your requirement
isn't for changes in C to be seen in B
Hi, I'm finally coming back to this problem, and I'd like to use a local cache
(B) to keep things simple. So far I found 2 ways to do that:
1. What you said - a TcpCacheLoader in B pointing at C, and (I guess) no
replication for B
2. B and C synchronously replicated in the same cluster, with no
About distributed TM, I know almost nothing about that, and have no idea where
to start.
With the local cache (B), if a node is locked for writing in B, will it be
also locked for writing in C, at the same time?
View the original post :
aditsu wrote : About distributed TM, I know almost nothing about that, and
have no idea where to start.
|
JBoss TS should have some literature around this, although I'd say you'd be
breaking new ground here as I don't know of any users using JBoss Cache with a
distributed TM.
aditsu wrote
Using a distributed TM may work and is worth trying out, as I'd imagine this is
the correct approach, provided C is configured with a
TransactionManagerLookup that knows how to get a handle on the distributed TM.
A simpler approach may be not to use a custom API to communicate between A and
C
An transaction is created internally only if optimistic locking is used. With
optimistic locking you have to configure a TransactionManager. With the
default pessimistic locking it is not required. (In releases before 1.4.1.SP
something the cache logs a WARN if you don't configure a TM, but
Yes.
You would want SYNC_REPL though.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3993956#3993956
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3993956
___
jboss-user mailing
If they run simultaneously, both transactions won't succeed. One of them will
fail since there will be a race condition to commit at the same time, and both
transactions will have locks on the node in question.
If you removed your sleep time, chances of success are higher, but there will
You can't. We don't do cluster-wide locks. :-) Remote locks are obtained on
transaction commit time.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3989748#3989748
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3989748
[EMAIL PROTECTED] wrote : If you removed your sleep time, chances of success
are higher, but there will still be that race condition. This is expected
since cluster-wide locks are not obtained when you read your node using a
cache.get().
Thanks!
But how can I obtain cluster-wide locks when
[EMAIL PROTECTED] wrote : You can't. We don't do cluster-wide locks. :-)
Remote locks are obtained on transaction commit time.
OK., Lets assume a situation where N services on N different JBoss instances
are reading and modifying data, how data integrity can be achieved? Only by
catching
Sorry, I can't boil it down to a simple junit test case.
And I have not more detailed error log...
May be later :)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3958534#3958534
Reply to the post :
[EMAIL PROTECTED] wrote : 1. Is it reproducible?
| 2. I have noticed that there is concurrent worker in the stack trace. Are
you updating the POJO concurrently? What is the update pattern? POJO is
supposed to have long lifetime under PojoCache.
1. Yes, but we can reproduce it in our project
OK, so this is concurrent update from the same cache instance (but
multi-threaded). If you can boil it down to a simple junit test case, that
would be the best case. If not, please email me the detailed error log again to
ben dot wang at jboss dot com.
thanks!
View the original post :
[EMAIL PROTECTED] wrote : Why dont you try it out from 1.4 release?
I have already tryied without success :
You are requesting file: /jboss/jboss-cache-dist-1.4.0.GA.zip
There was a problem downloading the file from surfnet.dl.sourceforge.net.
Please try a different mirror.
Your download should
Yes, we are using PojoCache and JBoss Transactions.
[EMAIL PROTECTED] wrote : Can you elaborate your test case? Looks like you
are using PojoCache. If that's the case, 1) if you are using tx yourself,
getCurrentTransaction() will return that tx, 2) if you are not, then I will
detect it and
16 matches
Mail list logo
