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 *i
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 i
"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" wro
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 :
http://www.jboss.com/index.html?module=bb&op=viewtopic&
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 it
Yes.
You would want SYNC_REPL though.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993956#3993956
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3993956
___
jboss-user maili
"[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 f
"[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
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=bb&op=viewtopic&p=3989748#3989748
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=398974
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
sti
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=bb&op=viewtopic&p=3958534#3958534
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=repl
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 :
http://
"[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 o
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.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopi
Thahk you for 1.4 GA release. There is resolved previous error.
But we have a new:
java.lang.RuntimeException: PojoCache.putObject(): fqn:
/poker/tournaments/1361/21/data at
org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:478) at
org.jboss.cache.aop.CacheInterceptor.invoke(CacheIntercep
Ben,
We later managed to pull this off a different mirror. We're testing again now.
Thanks,
Ilan
"KChvilyov" wrote : "[EMAIL PROTECTED]" wrote : Why dont you try it out from
1.4 release?
| I have already tried without success:
| Your download should begin shortly. If it does not, try
htt
"[EMAIL PROTECTED]" wrote : Why dont you try it out from 1.4 release?
I have already tried without success:
Your download should begin shortly. If it does not, try
http://superb-west.dl.sourceforge.net/sourceforge/jboss/jboss-cache-dist-1.4.0.GA.zip
or choose a different mirror
You are requesti
"[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
Why dont you try it out from 1.4 release? I assume you are grabbing the cvs
from JBossCache, of which is head for 2.0 now. We have branched out
JBossCache_1_4_GA that has the code fix (for 1.4).
I haven't ported the fix since I am doing heavy refactoring in head now. :-)
View the original post
Thank you for answers and questions.
We are not using any transaction in error situation. But is it necessary for
each operation with cache?
Last fix have not resolve our problem for using transactions with 1.4 version.
I have gotten last head JBossCache version from CVS.
Now error trase is:
06-0
Yes.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957216#3957216
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957216
___
jboss-user mailing list
jboss-user@lists.jboss.org
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 in
Hi, I have fixed on bug:
http://jira.jboss.com/jira/browse/JBCACHE-691
that I think if your problem. Basically, PojoCache will throw an exception if:
1. You are using other tm, e.g., JBossTransactionManagerLookup classs
2. You are not using any transaction, e.g., not tx.begin() in user code.
Can
This update appears to resolve the errors we were seeing. Is this included in
the GA release that was announced today?
"[EMAIL PROTECTED]" wrote : Hi, I have fixed one bug:
| http://jira.jboss.com/jira/browse/JBCACHE-691
| that I think is your problem. Basically, PojoCache will throw an exc
Have you got a transaction manager registered?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3956896#3956896
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3956896
___
jboss-us
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 initiate a transaction
internally. In this case, getCurrentTransaction should not b
27 matches
Mail list logo
