On 9 Jun 2011, at 15:26, Manik Surtani wrote:
We use partial state transfer not to generate partial state per cache, but
the entire state per cache, but since we have 1 cache sharing a given
JGroups channel, as far as JGroups in concerned this *is* partial state of a
node. I.e., the
This is a very tricky one indeed. These might fail as well e.g. if we increase
the number of concurrent threads running the test suite. I remember when
switching from 1 thread to 10 there were many of these failing.
I think your suggestion makes sense.
On 10 Jun 2011, at 13:02, Manik Surtani
On 9 Jun 2011, at 20:08, Manik Surtani wrote:
Are you suggesting #5 is superfluous and not needed?
No, just that it is already covered by #4, i.e. it is a duplicate.
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
I'll be mainly working on perf bechmark, so no deliverables from me.
On 7 Jun 2011, at 17:19, Manik Surtani ma...@jboss.org wrote:
Hi guys
What do we have in store for CR5? What's been committed since CR4, and
what's in the pipeline for CR5? Does a release on Monday (13th) make sense?
On 8 Jun 2011, at 11:44, Galder Zamarreño wrote:
On Jun 7, 2011, at 2:41 PM, Mircea Markus wrote:
On 7 Jun 2011, at 13:13, Sanne Grinovero wrote:
Hello all,
in this scenario we have the Infinispan Lucene Directory using
batching (DummyTransaction), eviction and passivation to keep
+1 CacheImp.
On 8 Jun 2011, at 13:50, Sanne Grinovero wrote:
+1, has been disturbing me as well :)
On Wed, Jun 8, 2011 at 12:51 PM, Manik Surtani ma...@jboss.org wrote:
+2 to CacheImpl, +1 to ComposedCache, -1 to CacheDelegate (i.e., I support
the rename)
On 8 Jun 2011, at 12:38, Pete
On 7 Jun 2011, at 13:13, Sanne Grinovero wrote:
Hello all,
in this scenario we have the Infinispan Lucene Directory using
batching (DummyTransaction), eviction and passivation to keep the
amount of memory being used for the index under control; I'm using
LIRS but experienced the same issue
On 1 Jun 2011, at 20:49, Scott Marlow wrote:
I posted a message on the as7-dev ml
(http://lists.jboss.org/pipermail/jboss-as7-dev/2011-May/002254.html),
about switching to use the TransactionSynchronizationRegistry.
Does Infinispan currently register Transaction synchronization objects?
On 31 May 2011, at 14:09, Vladimir Blagojevic wrote:
While working on ISPN-83 I realized that we have to form equality
relationships between all our transport related timeouts and verify that
the make sense as configuration instance is being processed.
Alphabetically we have the
On 2 Jun 2011, at 10:31, Mircea Markus wrote:
On 1 Jun 2011, at 20:49, Scott Marlow wrote:
I posted a message on the as7-dev ml
(http://lists.jboss.org/pipermail/jboss-as7-dev/2011-May/002254.html),
about switching to use the TransactionSynchronizationRegistry.
Does Infinispan
On 2 Jun 2011, at 14:33, Vladimir Blagojevic wrote:
On 11-06-02 11:42 AM, Mircea Markus wrote:
looks good to me! What do you think should be done when they are not
correct? Warning? Or even ConfigException perhaps?
My initial gut feeling would be ConfigException but I can see that being
On 2 Jun 2011, at 13:19, Scott Marlow wrote:
On 06/02/2011 05:31 AM, Mircea Markus wrote:
On 1 Jun 2011, at 20:49, Scott Marlow wrote:
I posted a message on the as7-dev ml
(http://lists.jboss.org/pipermail/jboss-as7-dev/2011-May/002254.html),
about switching to use
On 2 Jun 2011, at 15:09, Scott Marlow wrote:
On 06/02/2011 09:50 AM, Mircea Markus wrote:
On 2 Jun 2011, at 13:19, Scott Marlow wrote:
On 06/02/2011 05:31 AM, Mircea Markus wrote:
On 1 Jun 2011, at 20:49, Scott Marlow wrote:
I posted a message on the as7-dev ml
(http
So, the rule for activity in beforeCompletion is:
- a Sync registered via registerSynchronization may call either
registerSynchronization or registerInterposedSynchronization.
- a Sync registered via registerInterposedSynchronization may call only
registerInterposedSynchronization.
Why are we actually using JGroups' state transfer with replication, but
use our own state transfer with distribution ?
I don't know, but guess it's because each node has a different set of
keys so no node has the same state as another ?
You could still use JGroups state transfer;
On 1 Jun 2011, at 08:26, Jonathan Halliday wrote:
some general comments:
- preserving some subset of the existing transactional guarantees is all well
and good BUT if the user is relying on additional 'guarantees' that are not
preserved in all cases then they'll be in trouble. Therefore,
I'll hold on ISPN-1107 which is about measuring performance and switch to doing
fixes. I'll also take some issues from Manik's queue.
On 31 May 2011, at 22:42, Vladimir Blagojevic wrote:
I'll close ISPN-83 if I do not hear any negative feedback from Paul
about Infinispan flush tests that
On 25 May 2011, at 09:12, Galder Zamarreño wrote:
On May 24, 2011, at 11:36 PM, Mircea Markus wrote:
Hi,
This is re: http://community.jboss.org/wiki/PossibleLockingImprovements
I've created JIRAs for the locking optimisations as follows:
#1: https://issues.jboss.org/browse/ISPN
I think in both cases (repl and dist) it still may make sense in some cases.
E.g., in dist, if a node joins, existing owners could, rather than push data
to the joiner, just push a list of {key: version} tuples, which may be
significantly smaller than the values. The joiner can then
On 18 May 2011, at 17:23, Manik Surtani wrote:
On 18 May 2011, at 13:32, Sanne Grinovero wrote:
1. Suggesting deferring local locks till prepare-time: wouldn't this
create a potentially large number of transaction failures? Since write
skews and overwriting may become a problem if
3. Need to think more about this, around implications of correctness of
lock acquisition is reordered. But in terms of algorithm, sorting on
identity hashcode won't work since this will be different on different
requestor JVMs.
The algorithm does NOT sort on identity hash code, but
I'll take it.
On 18 May 2011, at 11:20, Manik Surtani ma...@jboss.org wrote:
On 9 May 2011, at 16:53, Galder Zamarreño wrote:
I've created https://issues.jboss.org/browse/ISPN-1094
Great. So I know this is a way off (maybe Infinispan 5.2 or 6?) but does
someone want to own it for now,
On 18 May 2011, at 12:44, Manik Surtani wrote:
Some thoughts:
1. Suggesting deferring local locks till prepare-time: wouldn't this create
a potentially large number of transaction failures? Since write skews and
overwriting may become a problem if this is allowed.
Not sure I get you,
yes, looks good.
On 16 May 2011, at 16:15, Galder Zamarreño wrote:
Hmmm, maybe you caught me in the middle of updating the wiki? Check the link
again...
On May 16, 2011, at 5:12 PM, Mircea Markus wrote:
Good stuff!
My only note is that there are some code snippets that are not code
would
expect that when I receive which notification the new view is already
installed and ready to go; actually I thought that was the case since
ever.
What would be the use cases to get the notification *before* the new
hash is installed?
Cheers,
Sanne
2011/5/11 Mircea Markus mircea.mar
Thanks, that helped!
On 12 May 2011, at 09:10, Dan Berindei wrote:
I disabled the Osmorc plugin and that seemed to stop it.
Dan
On Wed, May 11, 2011 at 8:50 PM, Mircea Markus mircea.mar...@jboss.com
wrote:
Hi,
Whenever I'm switching branches from 4.2.x to master the build in IDEA
Hi,
I've added a possible solution to https://issues.jboss.org/browse/ISPN-1049,
can you please take a look and tell me what you think?
Cheers,
Mircea
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
Hi,
The basic problem behind this is that I need to be notified when a new
consistent hash is installed.
ATM there isn't any support (of which I know) for a
@ConsistenHashChangeListener.
I'm thinking to add such notifications either:
a) internally: Observer pattern on DistributionManager
Mircea Markus mircea.mar...@jboss.com:
Hi,
The basic problem behind this is that I need to be notified when a new
consistent hash is installed.
ATM there isn't any support (of which I know) for a
@ConsistenHashChangeListener.
I'm thinking to add such notifications either:
a) internally
On 11 May 2011, at 15:53, Sanne Grinovero wrote:
2011/5/11 Mircea Markus mircea.mar...@jboss.com:
On 11 May 2011, at 13:29, Sanne Grinovero wrote:
First thing I thought when reading your email was OMG do we support
on-the-fly hash implementation changes? crazy!
That's obviously
Hi,
Whenever I'm switching branches from 4.2.x to master the build in IDEA takes
ages(even more, about 5 mins!!!). Most of the time is spent is Building
non-OSGi libraries for module...
Any idea on what can be done to speed things up?
Cheers,
Mircea
On 5 May 2011, at 03:18, Galder Zamarreño wrote:
Vladimir, from a HotRod protocol perspective we'd need a new operation but
after that the body, as Manik suggested, you could have javascript which the
HotRod server ignores and passes it to the distexec code which deals with it
On 29 Apr 2011, at 16:26, Olaf Bergner wrote:
Am 29.04.11 16:55, schrieb Galder Zamarreño:
On Apr 28, 2011, at 11:47 PM, Manik Surtani wrote:
We do now support JBoss Logging.
https://issues.jboss.org/browse/ISPN-380
@Galder, does JBoss Logging have support for what Mircea mentioned
:
Silly me, forgot the link: http://logback.qos.ch/manual/mdc.html.
Am 27.04.11 16:55, schrieb Mircea Markus:
Hi,
I'm looking into some logs for the a JBW demo : it has 4 caches deployed
on each node and lots of topology changes happen. It's close to
impossible to tell which log pertains
Hi,
I've set up some on documentation around the new transaction functionality:
- recovery, linked from the main documentation page:
http://community.jboss.org/docs/DOC-16646?uniqueTitle=false
- Synchronization:
http://community.jboss.org/wiki/InfinispanTransactions#Enlisting_Synchronization
I
I've just run the same on master and it fast forwarded smoothly:
http://pastebin.com/p5qs4rQt
On 28 Apr 2011, at 13:25, Sanne Grinovero wrote:
Hello,
I don't understand what happened; I'm having a clean master locally,
if I pull from upstream master I get many more changes than
expected,
, then Synchronization is fine provided you are in the same process as
the TM.
Ah right, so Synchronizations are useful only when writing to the cache is
optional. In other words if you use ISPN as a cache and not as a fully fledged
data store.
Jonathan.
On 04/27/2011 04:55 PM, Mircea Markus wrote:
Hi
Hi,
I'm looking into some logs for the a JBW demo : it has 4 caches deployed on
each node and lots of topology changes happen. It's close to impossible to tell
which log pertains to which cache, especially around the
DistributionInterceptorImpl.
Wouldn't it make sense that, for certain
Hi,
If recovery is NOT used, what would you recommend as the default way of
enlisting a transaction: XAResource or Synchronization?
Cheers,
Mircea
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
On 21 Apr 2011, at 12:38, Sanne Grinovero wrote:
2011/4/21 Manik Surtani ma...@jboss.org:
On 21 Apr 2011, at 11:10, Sanne Grinovero wrote:
thanks for resuming this topic;
some more thoughts:
2011/4/20 Manik Surtani ma...@jboss.org:
I think changing the merging interface won't solve
) and Base64 it. Then you
have a 1-to-1 mapping between the XID and a JMX-friendly String. :-) Or
maybe an SHA1 hash of the byte[].
yes,that would work as well. A long is smaller and (not that matters a lot)
cheaper to generate.
On 4 Apr 2011, at 12:46, Mircea Markus wrote:
Hi,
After
On 14 Apr 2011, at 15:30, Manik Surtani wrote:
Apologies for the late response.
On 13 Apr 2011, at 10:38, Emmanuel Bernard wrote:
In exchange for answers, I will improve at least the JavaDoc and maybe
create a wiki from this info.
Sounds like a fair exchange. :-)
I've tried to
IMO the large object methods would fit better in the Cache directly, vs
AdvancedCache.
The way I see it AdvancedCache exposes to the power user internal ISPN stuff -
stuff that's not generally needed by every day user. E.g. the interceptor
chain, the rpc manager etc.
Everything that is plain
On 12 Apr 2011, at 10:51, Dan Berindei wrote:
+1 for Externalizer/AdvancedExternalizer.
+1, we already do that for Cache/AdvancedCache.
Dan
On Tue, Apr 12, 2011 at 10:17 AM, Galder Zamarreño gal...@redhat.com wrote:
On Apr 11, 2011, at 12:06 PM, Galder Zamarreño wrote:
Guys, any
can't you run the Callable locally on a clone of it? If Callable is Clonable
then clone it in an orthodox manner, otherwise clone it by
serializing/deseralizing it.
On 11 Apr 2011, at 19:58, Vladimir Blagojevic wrote:
Sanne,
I thought about that as well but I do not see a way to ensure
I'm working full-speed on finishing JMX tooling on recovery. The coding might
be finished but the review will take longer, so not sure it will get in.
On 11 Apr 2011, at 11:09, Galder Zamarreño wrote:
Hi all,
I'm currently targeting BETA2 for this Friday. How does this sound? I know
some
On 8 Apr 2011, at 18:30, Emmanuel Bernard wrote:
Yes I think that would fit the bill. Let me give some more background
Background
In Hibernate OGM, we store collections in a single key essentially as a
SetMapString,Object ie as a set of tuples, esch tuple representing the
equivalent of
On 11 Apr 2011, at 13:14, Sanne Grinovero wrote:
2011/4/11 Mircea Markus mircea.mar...@jboss.com:
On 8 Apr 2011, at 18:30, Emmanuel Bernard wrote:
Yes I think that would fit the bill. Let me give some more background
Background
In Hibernate OGM, we store collections in a single key
; the XID- long mapping was his
idea. The way I see it recovery is resource manager specific.
I might be naive but clearly an AS admin would want some JMX tools to do
recovery too?
I'll ask to make see.
Cheers,
On Mar 28, 2011, at 12:53 PM, Mircea Markus wrote:
Hi,
After a chat
You can use radargun for that: radargun.sourceforge.net
Also useful for benchmarking perf between different configs.
On 23 Mar 2011, at 13:39, david marion dlmar...@hotmail.com wrote:
Bela,
Is there a way to start up the JGroups stack on every node without using
Infinispan? Is there some
Hi Jonathan,
We need to serialize the javax.transaction.xa.Xid received from TM in order to
back up information on other nodes. Xid is not serializable so we need to use
our internal Xid implementation in order to be able to de-serialize it.
This also means that XAResource.recover returns Xid
On 17 Mar 2011, at 10:52, Mircea Markus wrote:
On 17 Mar 2011, at 10:33, Jonathan Halliday wrote:
You'll need to store the content, not the Object. The interface has getters
to extract the field values which are primitive types and thus easy to
store. You'll need your own impl
)
Il giorno mercoledì 16 marzo 2011, Mircea Markus
mircea.mar...@jboss.com ha scritto:
This method can return more than cache names, some info about status would
be helpful as well.
E.g. verb to return all the cache names together with a status indicator:
defined, running, stopped.
On 16
ConfigurationException(String.format(you 're not allowed to
use %s and %s together, that, other));
but we could overload the constructor of CacheException ...
On 15 Mar 2011, at 16:15, Mircea Markus wrote:
Hi,
Not a biggie, but I think it would be nice to use this nicer syntax for
exception messages
On 8 Mar 2011, at 18:15, Manik Surtani wrote:
Hmm, maybe create a JIRA for it and start a poll on the user forum?
On 8 Mar 2011, at 18:07, Galder Zamarreño wrote:
I've seen a fair few threads like
http://community.jboss.org/message/590204#590204
+1. Same here. Might have been the same
Nice stuff!
On 5 Mar 2011, at 02:32, Manik Surtani wrote:
I know it's been a while since we spoke about this, but I now have a
(working) prototype of this work.
Changes to Infinispan core to accommodate this:
Looks good indeed!
On 4 Mar 2011, at 17:54, Olaf Bergner wrote:
I'm currently working on implementing Spring's forthcoming cache SPI for
Infinispan, aiming to contribute the results back to Spring. Since
Spring is unlikely to accept cache providers besides EHCache in
spring-context itself,
On 2 Mar 2011, at 17:43, Manik Surtani wrote:
As consistency models go, Infinispan is primarily strongly consistent (with
2-phase commit between data owners), with the exception of during a rehash
where because of eventual consistency (inability to get a valid response to a
remote GET)
Hi,
http://community.jboss.org/wiki/Transactionrecoverydesign
Any feedback appreciated!
Thanks,
Mircea
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
FYI: https://issues.jboss.org/browse/ISPN-957
On 22 Feb 2011, at 20:15, Patrick McFarland wrote:
On Tue, Feb 22, 2011 at 11:37 AM, Jonathan Halliday
jonathan.halli...@redhat.com wrote:
That's actually going to change your test semantics slightly. You may
want to run in both optimized and
On 28 Feb 2011, at 17:21, Manik Surtani wrote:
On 22 Feb 2011, at 16:37, Jonathan Halliday wrote:
That's actually going to change your test semantics slightly. You may
want to run in both optimized and non-optimized modes to ensure full
coverage - some code paths may not get exercised
Hi,
I've just run core's test suite with JBossTM and DummyTM.
The duration on my local machine are:
With dummy TM: 5:46.800s
With JBossTM: 5:23.671s
A explanation for JBossTM over performing DummyTM in spite keeping a tx log on
the disk (which dummyTm doesn't) is the fact that it has
I'll take care of this today.
On 20 Feb 2011, at 17:39, Erik Salter wrote:
+1, although we’ve been building it from source.
Erik
From: infinispan-dev-boun...@lists.jboss.org
[mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Tristan Tarrant
Sent: Sunday, February 20, 2011
Hi,
Infinispan 4.2.1.CR3 Ursus has been released. It fixes the XSD issue reported
here: https://issues.jboss.org/browse/ISPN-934
In order to avoid these mistakes in future we plan to add a release validation
process: https://issues.jboss.org/browse/ISPN-942.
Cheers,
Hi,
The build is broken, I'm looking into it:
http://hudson.infinispan.org/hudson/job/Infinispan-master-JDK6-tcp/154/
Cheers,
Mircea___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
On 15 Feb 2011, at 15:00, Pete Muir wrote:
Personally, I would leave the setters alone (except to add @Deprecated :-)
and add new fluent methods.
+1.
I also think we should get rid of these methods in 6.
On 15 Feb 2011, at 14:49, Vladimir Blagojevic wrote:
Guys,
I need to make some
Hi,
This is something Bela has brought up while working on integrating RELAY in
infinispan.
Right now it's the joiner (JoinTask) that broadcast the new CH to the cluster
members. In the case of RELAY, this wouldn't be that good as the joiner might
be on a remote site and this means a
On 9 Feb 2011, at 08:14, Galder Zamarreño wrote:
Hi,
Re: https://issues.jboss.org/browse/ISPN-293
I have an issue with my implementation that simply wraps the realRemoteGet in
DistributionInterceptor around a Callable:
Assume that cache is configured with Distribution(numOwners=1,
On 9 Feb 2011, at 12:34, Manik Surtani wrote:
What about putting the entire call on a separate thread much earlier in the
call stack? E.g., in the CacheDelegate? You get the added benefit of any
cache loading happening offline as well. Plus a much simpler impl. :)
+1.
Sent from my iPhone
solution without having to rely on your suggestion
which passes the test suite. I'll send a pull request and you (Mircea+Manik)
can have a look to it, and then we can decide :)
On Feb 9, 2011, at 2:32 PM, Mircea Markus wrote:
On 9 Feb 2011, at 12:34, Manik Surtani wrote:
What about
On 2 Feb 2011, at 14:47, Galder Zamarreño wrote:
Some comments, in:
name=idealdistribution/dist-sync-ideal-distribution.xml useEvenHashing=true
Does dist-sync-ideal-distribution.xml differ in any way to dist-sync.xml? The
reason I ask is cos reading the wiki, it seems like
Hi,
I've just added:
https://sourceforge.net/apps/trac/radargun/wiki/MeasuringDistribution
Cheers,
Mircea___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
On 2 Feb 2011, at 12:22, Vladimir Blagojevic wrote:
On 11-02-02 9:16 AM, Manik Surtani wrote:
We could add a simplified EmbeddedCacheManager constructor to maintain
most of the complexity of building a cache via a configuration but
overriding components via provided instances, this relates
On 2 Feb 2011, at 13:51, Vladimir Blagojevic wrote:
On 11-02-02 10:41 AM, Mircea Markus wrote:
+1 I believe this can coexist/complement current setters approach. I do
not see how this can affect JAXB. It should work.
you mean setXyzClass?
I agree that this can coexist but I think the point
On 2 Feb 2011, at 13:54, Manik Surtani wrote:
On 2 Feb 2011, at 13:51, Vladimir Blagojevic wrote:
On 11-02-02 10:41 AM, Mircea Markus wrote:
+1 I believe this can coexist/complement current setters approach. I do
not see how this can affect JAXB. It should work.
you mean setXyzClass?
I
the local node? Or does it
guarantee that all calls are remote?
It spreads the keys from each node to all nodes(including self) equally.
On 1 Feb 2011, at 13:11, Mircea Markus wrote:
Hi,
I've enhanced Radargun with an ideal distribution function: this is a
perfectly correct behaving
On 31 Jan 2011, at 21:24, Manik Surtani wrote:
Guys,
I see this in the code base:
https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/interceptors/DistributionInterceptor.java#L247
which has come in as a part of this commit:
Hi,
I've fixed 10 intermittent failures on core's test suite. Also fixed couple of
bugs when doing that.
Looking at the last 3 hudson runs, the test suite now looks quite stable:
http://hudson.infinispan.org/hudson/job/Infinispan-master-JDK6-tcp/124/org.infinispan$infinispan-core/testReport/
I only have a minor issue, I'll try and close it tomorrow.
On 27 Jan 2011, at 09:28, Galder Zamarreño wrote:
I'll give 4.2.1.FINAL a bit of time before we release. The EDG guys keep
working on stuff and they're entering JIRAs.
On Jan 26, 2011, at 6:22 PM, Erik Salter wrote:
Hi all,
I've reverted Hudson and added a JIRA for enabling JBossTM:
https://issues.jboss.org/browse/ISPN-898
On 25 Jan 2011, at 19:04, Manik Surtani wrote:
Done. But I see a fair few new failures on Hudson now. :)
On 25 Jan 2011, at 17:18, Vladimir Blagojevic wrote:
On 11-01-25 2:12 PM, Manik
On 26 Jan 2011, at 12:19, Manik Surtani wrote:
On 26 Jan 2011, at 12:17, Mircea Markus wrote:
On 25 Jan 2011, at 17:12, Manik Surtani wrote:
How's this for a solution:
1) Test suite remains the same
I don't think performance is affected by using JBossTM for test runs, I'll
need
On 25 Jan 2011, at 17:12, Manik Surtani wrote:
How's this for a solution:
1) Test suite remains the same
I don't think performance is affected by using JBossTM for test runs, I'll
need to check by running it
It should be quicker. There is no maintenance of a persistent tx log.
Not
On 25 Jan 2011, at 11:33, Pete Muir wrote:
On 25 Jan 2011, at 11:09, Galder Zamarreño wrote:
Rather than sleeping which is a bit rudimentary and might hide problems
(even after 10 seconds the cluster might not be formed due to env issues),
you could wait until the view contains 2
Hi,
Right now we are running our test suite using DummyTM.
This is mainly for suppling users with a default, lightweight TM. And avoid a
additional dependency.
Even though this worked well for us so far, this might not be such a good idea
after all: there are many not-so-obvious rules to be
On 24 Jan 2011, at 16:34, Sanne Grinovero wrote:
Seems a good idea, but it's also nice if we can keep the testsuite
quick to run;
The performance difference would result from TM doing write on the disk during
2PC prepare( I think it's after the prepare phase). This only happens if we run
On 21 Jan 2011, at 16:34, Galder Zamarreño wrote:
Hi,
Re: https://issues.jboss.org/browse/ISPN-845
This is causing issues with use cases such as the Hibernate 2LC. Imagine this
scenario:
tx.begin();
cache1.get();
cache2.put();
cache3.remove();
tx.commit();
At commit time, 3
901 - 986 of 986 matches
Mail list logo
