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
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&
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
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
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
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
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
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
___
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
_
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
__
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
___
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
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
___
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
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
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
__
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
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
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
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
___
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
_
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
@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
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
@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
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
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
_
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
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
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'
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
__
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.
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
_
@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
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
__
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
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
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
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
"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
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
___
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
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
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.
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
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
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
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
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
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
"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
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
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
Programmatically only, and it needs to be in a region that has the expiration
eviction algorithm configured.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4212540#4212540
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4
"jshowalter" wrote : The comments in the source for putForExternalRead say See
JBCACHE-848 for details around this feature., but that link is dead.
The link works for me ... it goes here:
https://jira.jboss.org/jira/browse/JBCACHE-848
View the original post :
http://www.jboss.org/index.html?mo
"jshowalter" wrote : Based on an earlier thread on this forum that I started,
and their response from JBoss (which I think was from you, Manik!) asking how
to avoid notification on put, we call setCacheModeLocal(true) for puts of data
read from the database as opposed to puts of new data. Will t
A new bug fix release on the 3.x Naga series has just been released. Read all
about it here:
http://jbosscache.blogspot.com/2009/02/jboss-cache-303ga-released.html
Cheers
Manik
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4212552#4212552
Reply to the post
No, it should be 3.0 as per the sample cfg files in the distro.
http://anonsvn.jboss.org/repos/jbosscache/core/tags/3.0.3.GA/src/main/resources/config-samples/local.xml
The sample files not working would cause some of the tests to fail and block
the release process.
View the original post :
ht
Hmm, there seems to be an issue with what was released vs what was tagged. Let
me investigate further, sorry about the disruption.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4212692#4212692
Reply to the post :
http://www.jboss.org/index.html?module=bb&op
"jshowalter" wrote : Okay, I found the docs. I've ported our code. Now we need
to deploy it into production, which is using Jboss 4.3.CP02 (and not easily
changed). Will we be able to do that, or are the versions too different to be
compatible?
Depends. You cannot upgrade the versions of JBC t
Found the issue and fixed it. Please download 3.0.3.GA again. If you grabbed
this from maven, please remove it from your local repository first.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4212869#4212869
Reply to the post :
http://www.jboss.org/index.ht
Yes, it would be completely independent of the cache setup that the app server
uses. Different IP and port would be recommended if you can do this,
especially for your multicast address.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213089#4213089
Reply to
You would need to use synchronous replication for such guarantees. A call -
e.g., cache.put() - will not return until the same call is successfully
executed across the cluster. And if a remote instance is attempting the same
thing, it will not complete until the call can be executed across the
Listeners. How you identify the caller is up to you though. Relying on thread
naming is a bit hackish, as is using a ThreadLocal variable.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213288#4213288
Reply to the post :
http://www.jboss.org/index.html?mod
For a write heavy scenario like a shared counter, yes.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213308#4213308
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213308
___
Report it as a feature request on 3.1.0
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214906#4214906
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214906
___
jboss-user mail
Configure an expiration policy. This way you can specify when objects expire.
In addition, you should change the EvictionActionPolicy from the default (only
evict from memory) to the RemoveOnEvictActionPolicy.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4
Depends on where you want your test to be targeted against. I would suggest
3.0.X for your test initially, but I don't expect to do another 3.0.X release
(unless something is critical) so it is best to make sure your test also works
against trunk (which will become 3.1.0 soon)
View the origina
Hi and sorry for not responding sooner.
putForExternalRead was designed to specifically work outside the scope of any
ongoing transaction, so that it does not cause any ongoing transaction to fail
and roll back if the pFER() call fails.
So this is why calls to ctx.lookUpNode() within the scop
Thanks for analysing this. Have you got a unit test that specifically
recreates this? It should be simple enough to simulate if it is a "classic
deadlock" as you say.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4217004#4217004
Reply to the post :
http:/
Failure to init the cache will mean that the cache is unusable.
Are you using 1.4.1.SP4? If so the problem should be fixed.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4217011#4217011
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=post
Thanks for the test.
"dukehoops" wrote : To follow up further. Below is a test i wrote trying to
capture above failure. When I run it I observe the following:
| - if no debugger is used, test passes
| - if I step through with a debugger when EvictCommand.perform calls
ctx.lookUpNode(fqn) the
Hmm, I don't see this failure on your test, even when running it on multiple
threads, etc. Are you seeing this issue in a live use case, or just when using
your debugger?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4217077#4217077
Reply to the post :
htt
"dukehoops" wrote : Side note: Configuration.writeSkewCheck defaults to false
(and not true as specified in JBC3 User Guide reference section Ch 12, p 104).
|
Well spotted. Thanks, corrected in trunk (3.1.0)
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4
Had a look at your test, and your test is invalid. Here's why:
Case 1: You have commented out the line marked N1. This works fine, since you
first do a pFER() and then a get(). Expected behaviour.
Case 2: Line marked N1 is not commented out. Here is what happens:
1. tx starts
2. read the
Also, parent locks are acquired first when creating children, if
lockParentForChildInsertRemove is true (see MVCCNodeHelper.wrapNodeForWriting())
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4217567#4217567
Reply to the post :
http://www.jboss.org/index.htm
Have you read https://www.jboss.org/community/docs/DOC-10254?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218557#4218557
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218557
_
Do you need a replicated cache or a standalone one? :-)
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218559#4218559
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218559
__
JMX should primarily be used for management information and not as a registry
of services, this is why the component is deprecated.
You should have your own code create and register the cache in JNDI and your
client code look up the cache from JNDI.
View the original post :
http://www.jboss.or
You have a good point. Perhaps as a recommendation, READ_COMMITTED should be
used *if* using JBC3, Hibernate + MVCC.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218569#4218569
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=
Have you specified any custom marshallers in your cfg?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218566#4218566
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4218566
___
why do you say RemoveOnEvictActionPolicy is the root cause? At what point do
you see the NPE, when calling cache.start()? What do you see in your stack
trace?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218565#4218565
Reply to the post :
http://www.jbo
removeNode() is a clustered call and will cause removal on all instances in the
cluster. It is also as efficient as an invalidate message (just sends an Fqn).
In fact, the only difference between removeNode() and invalidate is that
invalidate will not affect any cache loaders configured (if
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
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
__
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
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
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
"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
"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
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
"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
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
_
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
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
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
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
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
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
"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.
1 - 100 of 239 matches
Mail list logo
