Richard,
No plans as yet, but feel free to suggest this on the Infinispan dev mail list.
Sounds like something that may prove useful.
Cheers
Manik
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4270050#4270050
Reply to the post :
http://www.jboss.org/index
Marshalling/serialization... ?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4270049#4270049
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4270049
___
jboss-user mailing list
Have you tried compile-time weaving, just to compare and help isolate the
problem?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268040#4268040
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268040
___
Looks like there is no one else in your cluster?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262953#4262953
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262953
___
jboss-
Have you tried 3.2.1? There were some issues with certain context flags not
being picked up by the MVCCNodeHelper which were fixed in 3.2.1.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4259887#4259887
Reply to the post :
http://www.jboss.org/index.html?mo
@RichardTaylor you should be able to use it as a drop-in replacement.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4259879#4259879
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4259879
_
This was resolved in JBC 3.2.0 - see
https://jira.jboss.org/jira/browse/JBCACHE-1533
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4259871#4259871
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4259871
This is more a question for the JBoss Clustering forum rather than JBoss Cache,
since it is the HTTP session management code that removes sessions during a
shutdown.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4259869#4259869
Reply to the post :
http://w
Can you confirm the version of JBoss Cache used? It should be the same as what
JBoss AS uses.
re: 1, you also need to make sure you are using the same JGroups stack as the
app server
re: 2, which threads are these? Could you provide a thread dump?
View the original post :
http://www.jboss.o
Hi thanks for reporting, this is definitely a bug.
See https://jira.jboss.org/jira/browse/JBCACHE-1547
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4256923#4256923
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4256923
"ae" wrote :
| I assume you are referring to some thing like this (from the doc):
| // SNIP
|
Yes.
"ae" wrote :
| I wonder if you can explain it in a little more detail. I need some
clarification to my confusions:
| - when is the lock obtained? is it, like the write lock, at
Have a look at Hibernate, again. :-) They too use INVALIDATION, and there is
a way to deal with this - it's called putForExternalRead().
As for the CL approach, that will not work, this scenario is not what the CL is
designed for.
View the original post :
http://www.jboss.org/index.html?modu
I think you are using the cache loader in an incorrect way. CLs are designed
to be a persistent (and overflow) extension to memory and should never be sued
to store a different form of data. And should also never change externally
outside the cache system.
If you want to cache stuff from a da
You can force write locks for a read. There is an Option for this (see the
Options API). When used with MVCC, this gives you an exclusive (write) lock,
when when you are reading. And when combined with a transaction, this means
you hold the write lock until the tx completes.
View the original
It could. Feel like contributing a patch? :)
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4256699#4256699
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4256699
___
jboss-us
depends what you want to use it for.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4256697#4256697
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4256697
___
jboss-user mailing
PLease use the CODE button when posting XML
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4256693#4256693
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4256693
___
jboss-user
Remove removes stuff in cache loaders as well. Evict just evicts from memory.
Also, evict will fail (no-op) if someone else has a lock on the node. Remove
will wait for lockAcquisitionTimeout millis to try and acquire the lock and
succeed before failing.
View the original post :
http://www.
Now in blog-article form! Vote it up below, and enjoy reading!
http://digg.com/programming/Distribution_instead_of_Buddy_Replication
http://www.dzone.com/links/distribution_instead_of_buddy_replication.html
- Manik
View the original post :
http://www.jboss.org/index.html?modul
Detail;s here, in my blog:
http://jbosscache.blogspot.com/2009/08/jboss-cache-320-malagueta-just-released.html
Enjoy!
Manik
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251137#4251137
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=postin
Have a look at this for help:
http://galder.zamarreno.com/?p=227
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251131#4251131
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251131
___
"steeven" wrote :
| another question, how to make the server readonly? the server will accept
changes from client side. it is dangerous for my case.
|
Hmm. You could make the client not push writes to the server by using the
ignoreModifications attrib to the cacheLoader element.
You coul
Try increasing your concurrencyLevel.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250730#4250730
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4250730
___
jboss-user mailin
1) don't use buddy replication for the server nodes. Since there are only 2,
you don't need BR.
2) don't even bother with REPL. Use INVAL since they are backed by the DB.
This will reduce chattiness and traffic between the server nodes.
3) You don't need singletonStore for the server nodes
do you have any concurrent transactions accessing (writing to) that same fqn?
If so, it could mean that you just need a greater lock acquisition timeout...
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250596#4250596
Reply to the post :
http://www.jboss.o
Using this option, you can force some invocations to be async even though the
general cache is set up to be sync.
But you cannot make the calls sync to some members and async to others.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250336#4250336
Reply to t
Any chance of upgrading to something more modern? I'm about to cut 3.2.0.GA
this week. :)
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250114#4250114
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4250114
__
@mukulb wdyt? :)
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249377#4249377
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249377
___
jboss-user mailing list
jboss-user@li
Nice and easy! :-) We should document this on a wiki somewhere.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249375#4249375
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249375
_
One way to do this - and this would involve extending or modifying the MC - is
to replace whatever backing container the MC uses to store beans it creates
(probably a Map) with an Infinispan Cache.
This should be trivial since org.infinispan.Cache extends
java.util.concurrent.ConcurrentMap.
TreeCacheMBean was deprecated in 2.x and removed in 3.x.
Look for CacheJmxWrapperMBean instead.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4248482#4248482
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4248482
__
Hi, sorry for the late response.
1) Red Hat does offer paid support for JBoss Cache as a part of the JBoss EAP
subscription.
2) Interesting that using the dummy TM solves the problem - it is still a real
TM capable of holding real locks. It's just that other components in the app
server won'
Set async = true in your cache loader configuration?
Also, maybe you should try asynchronous replication rather than persisting to a
JDBC cache loader.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237436#4237436
Reply to the post :
http://www.jboss.org/in
Thanks
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237435#4237435
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237435
___
jboss-user mailing list
jboss-user@lists.jboss.o
Could you please create a JIRA for this, for us to investigate.
Thanks
Manik
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237245#4237245
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237245
_
Have you tried forcing a gc() after the end of your generation loop?
Also, perhaps JDBM is caching stuff in memory as well, maintaining different
versions. Have you looked at the JDBM docs/code to see if this is the case,
and how this can be disabled?
Cheers
Manik
View the original post :
ht
@sridhar_ratna first off, you don't need C3P0 with JDBM. C3P0 is only to do
with the Jdbc Cache Loader.
It seems there is a mem leak somewhere, when a Map is used as a value. Do you
know if you still have this problem if you use a different cache loader impl,
such as BDBJE or a FileCacheLoa
That stack trace should only be for HA-JNDI. Local JNDI should not try and
serialize anything (unless I am mistaken).
Re: clustered caches, there should be no issue with
serialization/deserialization as JNDI should not require this.
View the original post :
http://www.jboss.org/index.html?mod
@Mircea - you should be able to bind to JNDI. This is useful not only for
local mode, but even clustered modes where you want to share 1 cache instance
across several webapps/enterprise apps in the same container.
@gsoing - however, there is no point in putting the cache in a HA-JNDI server
si
Are you binding this to a HA-JNDI instance? There would be little value in
that... you do want to bind to local JNDI.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235177#4235177
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode
if, in jboss cache, you have fetch state on startup enabled, a rejoin will
trigger a state transfer.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4233301#4233301
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4233301
_
CNFE? Have you set a special class loader on your region or something?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4231005#4231005
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4231005
___
Sorry, I don't actually have a DB2 environment to test on.
Do you know what characters DB2 refers to as 'parameter markers'?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230399#4230399
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=post
Could you enable TRACE level logging on org.jboss.cache.loader so that we can
see the SQL that is being generated?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230360#4230360
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=re
Switch off clustering then. Make sure you set your cache mode to LOCAL.
I would also recommend using a more recent version of JBoss Cache, e.g., 3.1.0
is the current stable release.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230347#4230347
Reply to the
Sure - you could have your own cache loader impl that does that.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228962#4228962
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228962
__
Try smaller transactions? Add more memory? :-)
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228892#4228892
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228892
___
jboss-u
There is a lot of overhead in maintaining the tree structure. The overhead
varies with the type of data stored, and if you have a lot of small key/value
pairs then the overhead increases quite significantly. This is one of the
motivations for starting the Infinispan [1] project.
One thing you
Sure, feel free to contribute a patch for the next JBC release.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228680#4228680
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228680
___
Multiple JBC instances can and will participate in the same JTA transaction.
E.g.,
| tx.begin()
| cache1.put(...)
| cache2.remove(...)
| cache3.put(...)
| tx.commit()
|
will work.
Not sure I understand your problem about not being able to do replication. Do
you run out of memo
you need jdbcConfig.setClassName("org.jboss.cache.loader.JDBCCacheLoader")
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228581#4228581
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228581
___
Use the code button when posting XML - makes things much more readable. :-)
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228580#4228580
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228580
__
Pessimistic locking is prone to deadlocks. This is why it is deprecated.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228578#4228578
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228578
_
Does it work if you use the default JNDI port of 1099?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228576#4228576
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228576
___
Can you access this via jconsole rather than the JBoss JMX console? Just to
help isolate the problem...
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228573#4228573
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228
Read the section on "How Nodes Are Evicted" in the JBoss Cache user guide.
http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs/3.0.3.GA/userguide_en/html/eviction_policies.html#d0e3326
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=422857
synchronously.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228568#4228568
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228568
___
jboss-user mailing list
jboss-user@lists
Using the overrides would be a hack.
For evicting all nodes, caches start empty anyway unless you have state
transfer or preloading from a cache loader enabled. But if you want to evict
everything, I'm guessing you don't have these two enabled?
View the original post :
http://www.jboss.org/in
Mingfai,
Have you had a look at Infinispan? http://www.infinispan.org - you may want to
look at using this with Grails as well.
Cheers
Manik
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228551#4228551
Reply to the post :
http://www.jboss.org/index.htm
Details on my blog:
http://jbosscache.blogspot.com/2009/05/jboss-cache-310-cascabel-in-final.html
Enjoy!
Manik
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228550#4228550
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&
I'd like to announce Infinispan [1], the spiritual successor to JBoss Cache.
Read all about it on the Infinispan blog [2]. And for those of you wondering
about the future of JBoss Cache, this is addressed in the Infinispan FAQs [3].
Also note that Infinispan 4.0.0.ALPHA2 [4] is now available f
There could be a number of reasons why the cache would load from the loader.
Do you have a unit test that shows an access pattern where unnecessary loading
takes place?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225562#4225562
Reply to the post :
http:
anonymous wrote :
| JBoss Cache folks are bad guys :)
|
You bet we are! ;-) Fixed the docs in JBC trunk.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225336#4225336
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=repl
Have you tried updating to a newer version of JBC?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224651#4224651
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224651
___
jbos
:-) Apart from lock acquisition timeouts and data versioning exceptions,
that's really it. These could happen both locally and remotely, of course.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224650#4224650
Reply to the post :
http://www.jboss.org/index
"zeravlai" wrote :
| apart from the DataVersioningException with R_R, is there any other way
that a transaction could abort under MVCC ??
|
| Question is because wikipedia MVCC reference (which is pointed in the JBC
document), talks about transactions aborting and restarting. Is there suc
Preload.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223738#4223738
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223738
___
jboss-user mailing list
jboss-user@lists.jboss
It is an internal detail that prevents such a check in R_C. That internal
detail is that I maintain a direct reference to the cached state. So if it
changes (by another tx) I do not know this.
Now with R_R, I do know this since I maintain a copy to the cached state. And
I can check if my c
Depends. Are you using Firebird as a DB for the JDBC Cache Loader in JBC? Or
is this for your JPA persistence?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223596#4223596
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply
Yes, since what is an increment to you (i++) is actually a set to the cache
(e.g., set i = blah) where blah has been pre-calculated based on an old value
read. So even if you have R_C, even though your tx is re-reading the field at
the time of setting, your application is not.
Basically, with
If you are referring to a cache loader, I can't imagine why you would use a
cache loader if you are using JBC with Hibernate, since Hibernate already
provides persistence.
Using cache loaders with JBC is really for cases where you want cached
in-memory state to be persisted (e.g., to disk or a
"zeravlai" wrote : BTW, don't take this error into account and please keep on
answering my future questions ;-)
LOL! No worries!
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223586#4223586
Reply to the post :
http://www.jboss.org/index.html?module=bb&op
Yep, start a wiki page. Good man. :-)
Feel free to post comments here as well if you need more help/need questions
answered.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223258#4223258
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=pos
"zeravlai" wrote : 1- If the transaction already has a read lock on the entity
(which is acquired by an EntityManager.find() ) the read lock will be
INMEDIATELY upgraded to write lock, EVEN if there's a concurrent transaction
which already has a read lock on the same entity.
|
Can you confir
You're best off looking at the src code of one of the existing policies...
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223251#4223251
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223251
___
Details on my blog,
http://jbosscache.blogspot.com/2009/04/jboss-cache-310cr1-released.html.
Enjoy!
Manik
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223079#4223079
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=422
A reasonable request. Something for us to think about moving fwd.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222571#4222571
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222571
You need to look into your logs and determine why a transaction failed. It
could be any number of reasons.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221860#4221860
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=42
You'd use a key. A dummy key if it is irrelevant to you, e.g., a public static
final Object DUMMY_KEY that you could define.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221427#4221427
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posti
"zeravlai" wrote : Also Manik, in "mvcc-entity" predefined cache config,
there's a comment saying that READ_COMMITTED is as strong as neccesary for most
2nd level cache use cases. What's the meaning of this sentence bearing in mind
your reply ?
R_C is (slightly) more efficient that R_R in our M
Do you actually see the changes on your remote cache?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221203#4221203
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221203
___
j
"jshowalter" wrote :
| - "if all of the data in a node ages out of the cache due to LRU, is the
data removed from the cache and the node left in place, or is the node also
removed"?
|
Like I said, the unit of atomicity is a node. So, it is an entire node that
times out due to LRU, not an
Hibernate has a first level cache in it's session. Which will provide you with
R_R regardless of how your second level cache is configured.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220896#4220896
Reply to the post :
http://www.jboss.org/index.html?mo
"jshowalter" wrote :
| We realize this is by design and documented as such, but the design puzzles
us. The put should succeed if the node is there but the key for the data being
put is missing, and should succeed if the node and key are there but the value
in the node for that key is null.
You will still need it since JBC is compiled against JGroups and a lot of the
internal components use JGroups building blocks. You will end up with class
not found errors if you try and run JBC without JGroups.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4
I've just released Beta1 on JBC 3.1.0 "Cascabel". Details on my blog:
http://jbosscache.blogspot.com/2009/03/jboss-cache-310beta1.html
Enjoy
Manik
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220012#4220012
Reply to the post :
http://www.jboss.org/index.h
Thanks, will take a look.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4219472#4219472
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4219472
___
jboss-user mailing list
jboss
More than the cfg file, is the expiry information set on the node on all cache
instances?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4219044#4219044
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4219044
Then don't remove the clustering section of your config file. :-)
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4219037#4219037
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4219037
Yes this is possible, there are several discussions on the forums on the
subject. Also, the guide you refer to does apply to JBC3 as well.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4219036#4219036
Reply to the post :
http://www.jboss.org/index.html?mo
Is the expiry time set on all cache instances in the cluster?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4219034#4219034
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4219034
_
"dukehoops" wrote :
| 1. the pattern I described in the post linked below is not an edge case:
| http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4217616#4217616
|
I agree that the pattern is not an edge case for Hib/JBC3 integration, but it
is an edge case for JBC3 in general. R
https://jira.jboss.org/jira/browse/JBCACHE-1493
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218759#4218759
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218759
___
jboss-u
"bstansbe...@jboss.com" wrote : You only modify data that you read? What if I
just call removeNode() with no preceding get()?
|
Then the read happens at the time of the removeNode(). I.e., the node to be
removed is read from the data structure, then marked as removed and finally
removed wh
"bstansbe...@jboss.com" wrote :
| Manik, why is the removeNode call not removing the node? Is the MVCC code
detecting that the node didn't exist when the get() call happened and therefore
turning the removeNode into a no-op?
|
Yes. This is consistent with R_R semantics in that you only mo
Yes, since evicting will only remove stuff from memory not from a cache loader.
If you want to remove stuff from the loader as well, I would recommend
upgrading to JBC 3 and using a RemoveOnEvictActionPolicy (see sample configs
that ship with JBC 3)
View the original post :
http://www.jboss.or
Sounds like https://jira.jboss.org/jira/browse/JBCACHE-1454.
This is fixed in 3.0.2.GA. Is it possible to upgrade?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218600#4218600
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=re
Submit a feature request. I can add this to 3.1.0.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218599#4218599
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218599
___
jbo
Use a Cache Listener and register for the NodeEvicted callbacks.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218597#4218597
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218597
__
In general, I would recommend using JNDI over JMX for this. JMX is really
designed for manamenent information and not as a component registry.
Here is a document (http://www.jboss.org/community/docs/DOC-10252) on how this
can be done on WebLogic.
Here is a similar doc for WebSphere
(http://ww
1 - 100 of 239 matches
Mail list logo
