Implicit locking
by Vladimir Blagojevic
Hey,
I want to start working on [1]. Which operations do we want to include
into transparent implicit eager locking? All operations that are
WriteCommand(s)?
I want to add boolean attribute useEagerLocking in transaction
configuration element. If you object to this name, speak up!
Regards,
Vladimir
[1] https://jira.jboss.org/jira/browse/ISPN-70
17 years
Jopr Plugin ...
by Heiko W.Rupp
Some fun with the standalone container (http://javablogs.com/Jump.action?id=503502
) below... :-)
Why are the cachesDefined and cachesCreated attributes on the
InfinispanManager Strings?
Heiko
snert:/jon/jonHEAD/rhq/modules/enterprise/agent/target/rhq-agent hrupp
$ bin/standalone.sh
Listening for transport dt_socket at address: 8788
Starting the plugin container.
Loading plugins
...Loaded plugin: Platforms
...Loaded plugin: JMX
...Loaded plugin: infinispan
Ready.
[0]:0 > disc all
Discovery took: 2334ms
[Resource[id=-30, type=Cache, key=org.infinispan:cache-
name=myCustomCache(local),jmx-resource=CacheMgmtInterceptor,
name=org.infinispan:cache-name=myCustomCache(local),jmx-
resource=CacheMgmtInterceptor, parent=Infinispan Manager],
......
[1]:0 > find rt Cache
-30: org.infinispan:cache-name=myCustomCache(local),jmx-
resource=CacheMgmtInterceptor ( Resource[id=-4, type=infinispan,
key=org.infinispan:cache-name=[global],jmx-resource=CacheManager,
name=Infinispan Manager, parent=snert] )
[2]:0 > set r $r
[3]:-30 > i Tx.resetStatistics
[]
[4]:-30 > m m Mgmt.averageWriteTime
No data returned
[5]:-30 > m m Mgmt.averageWriteTime
MeasurementDataNumeric[value=[14,00], MeasurementData
[MeasurementDataPK: timestamp=[23.05.09 22:04], scheduleId=[1]]]
[6]:-30 >
17 years
More on marshallers - affects cache store authors again!
by Manik Surtani
Guys
I've made a few changes regarding marshalling.
1) Removed Serializable/Externalizable where unnecessary. There may
well be more places where we can drop this interface - do let me know
if I have missed anything. The purpose of removing Serializable/
Externalizable is to force all serialization to go through the
Marshaller interface, which is tuned for performance and reduced byte
array size.
2) Some classes relied on Object serialization. Added marshall/
unmarshall methods for these. E.g., Bucket. Galder, you may want to
do the same with your JBMAR externalizers.
3) Moved (write|read)Unsigned(Int|Long) from MarshallerImpl to static
helpers on org.infinispan.io.UnsignedNumeric so that they can be
consumed from elsewhere as well, such as Galder's Externalizers. Feel
free to use these, they produce a more compact byte stream when
serializing unsigned longs and ints, especially if their value is small.
4) Renamed ObjectStreamMarshaller - a dummy marshaller for testing -
to TestObjectStreamMarshaller. Also, this marshaller now uses XStream
to write objects to an XML stream before writing the result to a JDK
ObjectOutputStream. The purpose is that the test marshaller can now
deal with non-Serializable classes. The XStream dependency is for
tests only, as you would expect.
Please revisit how your cache store implementations use streams.
Remember, never directly read to or write from a stream, use the
marshaller instead!
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
17 years
Query API, JPA and a fine-grained model
by Manik Surtani
So the plan is that we would implement a new fine-grained model to
replace POJO Cache. Rather than AOP, we would use a JPA-like session-
style interface where we can track changes made to state in a session
to detect field changes [1]. This hugely simplifies the
implementation and makes things more robust, plus provides people with
a familiar JPA API to use.
Now considering the query API, if we are already providing a JPA
interface, this is another reason for the query API to support JPA-QL
rather than just Lucene queries.
The other reason, of course, is easy migration off using databases for
persistence to using a data grid for persistence [2]. Now, naturally,
the designs outlined in [2] can easily be achieved using Hibernate and
a good distributed cache, but what happens when you don't actually
want to persist your data at all, just want it to live in a grid
(because you think your grid is "good enough" to not be unavailable,
and/or your data is transient or can be recalculated), but you still
want to use a JPA interface because either you are more familiar with
it, or you started off storing this state in JPA and are now
rethinking your persistence needs but don't want to rewrite your app.
Of course, supporting JPA-QL in a distributed cache query API is not
trivial. We know we can do this fairly easily with Lucene queries.
Does anyone know of a mechanism to translate between these easily
enough? If need be, this is something we could build. JPA-QL grammar
is finite and an ANTLR [3] definition to translate these to Lucene
query objects shouldn't be too hard ...
Thoughts?
Manik
[1] http://www.jboss.org/community/wiki/NewFineGrainedReplicationAPIDesign
[2] http://web2.sys-con.com/node/951117
[3] http://www.antlr.org/
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
17 years
Re: Infinispan and search APIs
by Ray Hilton
Hi guys,
I've been trying to get jbc-searchable working with JbossCache 3, but then I
noticed this thread for Infinispan. I am trying to build a proof-of-concept
for a distributed searchable cache, and obviously infinispan with hibernate
search would be an ideal solution. At what stage of development is this?
Is it possible to use the existing jbc-searchable code with infinispan?
Should I perhaps stick with jbc for now?
On a related note, I like the idea that each node builds and stores its own
indices for data it currently hosts. It would also be nice if these indices
could be further partitioned (in our case, we would like to do this per-day,
other situations maybe based on a modulous of the hash code) to reduce the
size of the indices. Replicated indices are ok if they dont change that
often, but ours will be updated almost constantly, and so you either need to
nominate one node to do the work, or have some distributed locking in place,
which would probably kill performance. Building an index locally also
provides protection against index corruption by having redundant copies
around the grid. We are intending to do deduplication and score
normalization ourselves.
I also tried using the jbosscache-lucene Directory implementation that Manik
wrote, but things started to die when lucene tried to merge segments. Has
there been any work to create a infinispan-backed lucene Directory?
Regards,
Ray Hilton
17 years
Re: [infinispan-dev] config migration scripts
by Mircea Markus
Christophe Hivert wrote:
> Yes, a unit test where you actually load the produced xml would be great.
>
org.infinispan.config.parsing.Jbc2InfinispanTransformerTest.
UT revealed quite some issues in the result file, even though the result
was syntactically correct, as per XSD.
> Just curious, do you guys have any code review process?
>
> Thanks,
> Christophe.
>
> -----Original Message-----
> From: Mircea Markus [mailto:mircea.markus@jboss.com]
> Sent: Monday, May 18, 2009 2:50 AM
> To: Manik Surtani
> Cc: infinispan-dev(a)lists.jboss.org; Christophe Hivert
> Subject: Re: [infinispan-dev] config migration scripts
>
> Manik Surtani wrote:
>
>> On 18 May 2009, at 05:11, Mircea Markus wrote:
>>
>>
>>> I've enhanced the scripts to create an xml from inlined JGroups
>>> config, also a script to indent the xml output.
>>>
>>> importConfig.sh and importConfig.bat were added as well, they are
>>> placed in /bin when running dist.
>>>
>>> I still have to add an UT to check the semantical correctness of the
>>> transformation.
>>>
>> Great - Christophe is writing the EHCache transformation and Adrian's
>> doing the Coherence one, these should be checked for correctness as well.
>>
>> Cheers
>> Manik
>>
> Ah great!
> Christophe, Adrian let me know if I can help...
>
>>> Manik Surtani wrote:
>>>
>>>> So I suppose the way this is going to work, is something like:
>>>>
>>>> $ ./migrateConfig.sh --format ehcache src_config.xml
>>>> target_config.xml ?
>>>>
>>>> where usage would be something like:
>>>>
>>>> $ ./migrateConfig.sh --help
>>>>
>>>> Usage:
>>>> migrateConfig --format <ehcache | jbosscache | coherence>
>>>> /path/to/src.xml /path/to/output.xml ?
>>>>
>>>> Cheers
>>>> Manik
>>>>
>>>> On 15 May 2009, at 11:34, Mircea Markus wrote:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> I've just added /src/resources/xslt/jbc3x2infinispan4x.xslt for
>>>>> migrating config files from JBossCache to Infinispan.
>>>>> I'll also add the .bat and .sh shortly + a java class to
>>>>> instantiate the transformer.
>>>>>
>>>>> Cheers,
>>>>> Mircea
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> infinispan-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>> --
>>>> Manik Surtani
>>>> manik(a)jboss.org
>>>> Lead, Infinispan
>>>> Lead, JBoss Cache
>>>> http://www.infinispan.org
>>>> http://www.jbosscache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>> --
>> Manik Surtani
>> manik(a)jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>>
>>
>>
>>
>>
>
>
17 years
Set of keys modified in tx
by Vladimir Blagojevic
Manik,
Recall our conversation regarding adding a set of modified keys to tx
context. You said how we can have "this set of keys updated by the
TxInterceptor after a in-tx-scope completion of every write command".
It seems that the best way to collect these keys is to add them in
TxInterceptor#enlistWriteAndInvokeNext right where we add modifications
to xaAdapter. And also the easiest way to lookup modified keys seems to
be from ctx#getLookedUpEntries(). Traverse entries, get keys and copy
them into a set in TransactionXaAdapter.
Agree?
17 years
First working version of lock/unlock API
by Vladimir Blagojevic
Hey Manik,
Do not need Mircea's help. I turned on debugger and went to investigate
why I was getting NPEs in those invocations. So now I have first working
version of locking/unlocking working with transactions (see
SyncReplLockingTest). Will add more tests and continue to play with this
one.
All in all - loads of fun. As soon as I am done with this one and
implicit transactions I want more tasks :)
Regards,
Vladimir
17 years
Improved Marshaller
by Manik Surtani
I just checked the following in trunk.
Galder, you may want to do something similar for your JBMAR prototype.
The changes are around InternalCacheEntry and now InternalCacheValue.
Previously, the marshaller stored an InternalCacheEntry as [key,
value, canExpire, created, lifespan, lastUsed, maxIdle], setting
either of the last 4 elements to -1 if they are unused. In a system
mainly comprising of mortal values, this is wasteful since each of the
last 2 values - which would be unused - are longs and still written to.
So this change identifies the InternalCacheEntry and writes just what
is needed, hence the use of specific magic numbers for each of the
InternalCacheEntry implementations. Using a different magic number
for each entry type allows me to trim what is written.
Same approach used for InternalCacheValue.
Yes, even more ugly switch statements - and this is why we need JBMAR
to clean this up - if and when it can match performance and
compactness of the resulting byte array. :-)
Cheers
Manik
Begin forwarded message:
> From: infinispan-commits(a)lists.jboss.org
> Date: 8 May 2009 12:37:23 BST
> To: infinispan-commits(a)lists.jboss.org
> Subject: [infinispan-commits] Infinispan SVN: r234 - trunk/core/src/
> main/java/org/infinispan/marshall.
> Reply-To: infinispan-commits(a)lists.jboss.org
>
> Author: manik.surtani(a)jboss.com
> Date: 2009-05-08 07:37:23 -0400 (Fri, 08 May 2009)
> New Revision: 234
>
> Modified:
> trunk/core/src/main/java/org/infinispan/marshall/MarshallerImpl.java
> Log:
> Improved marshaller
>
> Modified: trunk/core/src/main/java/org/infinispan/marshall/
> MarshallerImpl.java
> ===================================================================
> --- trunk/core/src/main/java/org/infinispan/marshall/
> MarshallerImpl.java 2009-05-08 11:36:59 UTC (rev 233)
> +++ trunk/core/src/main/java/org/infinispan/marshall/
> MarshallerImpl.java 2009-05-08 11:37:23 UTC (rev 234)
> @@ -26,8 +26,13 @@
> import org.infinispan.commands.RemoteCommandFactory;
> import org.infinispan.commands.ReplicableCommand;
> import org.infinispan.commands.write.WriteCommand;
> +import org.infinispan.container.entries.ImmortalCacheEntry;
> import org.infinispan.container.entries.InternalCacheEntry;
> +import org.infinispan.container.entries.InternalCacheValue;
> import org.infinispan.container.entries.InternalEntryFactory;
> +import org.infinispan.container.entries.MortalCacheEntry;
> +import org.infinispan.container.entries.TransientCacheEntry;
> +import org.infinispan.container.entries.TransientMortalCacheEntry;
> import org.infinispan.io.ByteBuffer;
> import org.infinispan.io.ExposedByteArrayOutputStream;
> import org.infinispan.remoting.responses.ExceptionResponse;
> @@ -94,14 +99,23 @@
> protected static final int MAGICNUMBER_SINGLETON_LIST = 23;
> protected static final int MAGICNUMBER_COMMAND = 24;
> protected static final int MAGICNUMBER_TRANSACTION_LOG = 25;
> - protected static final int MAGICNUMBER_INTERNAL_CACHED_ENTRY = 26;
>
> + // --- cache entries and values ---
> + protected static final int MAGICNUMBER_ICE_IMMORTAL = 26;
> + protected static final int MAGICNUMBER_ICE_MORTAL = 27;
> + protected static final int MAGICNUMBER_ICE_TRANSIENT = 28;
> + protected static final int MAGICNUMBER_ICE_TRANSIENT_MORTAL = 29;
> + protected static final int MAGICNUMBER_ICV_IMMORTAL = 30;
> + protected static final int MAGICNUMBER_ICV_MORTAL = 31;
> + protected static final int MAGICNUMBER_ICV_TRANSIENT = 32;
> + protected static final int MAGICNUMBER_ICV_TRANSIENT_MORTAL = 33;
> +
> // ---- responses
> - protected static final int MAGICNUMBER_REQUEST_IGNORED_RESPONSE
> = 27;
> - protected static final int MAGICNUMBER_EXTENDED_RESPONSE = 28;
> - protected static final int MAGICNUMBER_EXCEPTION_RESPONSE = 29;
> - protected static final int MAGICNUMBER_SUCCESSFUL_RESPONSE = 30;
> - protected static final int MAGICNUMBER_UNSUCCESSFUL_RESPONSE = 31;
> + protected static final int MAGICNUMBER_REQUEST_IGNORED_RESPONSE
> = 34;
> + protected static final int MAGICNUMBER_EXTENDED_RESPONSE = 35;
> + protected static final int MAGICNUMBER_EXCEPTION_RESPONSE = 36;
> + protected static final int MAGICNUMBER_SUCCESSFUL_RESPONSE = 37;
> + protected static final int MAGICNUMBER_UNSUCCESSFUL_RESPONSE = 38;
>
> protected static final int MAGICNUMBER_NULL = 99;
> protected static final int MAGICNUMBER_SERIALIZABLE = 100;
> @@ -173,19 +187,9 @@
> } else if (o instanceof Response) {
> marshallResponse((Response) o, out, refMap);
> } else if (o instanceof InternalCacheEntry) {
> - out.writeByte(MAGICNUMBER_INTERNAL_CACHED_ENTRY);
> - InternalCacheEntry ice = (InternalCacheEntry) o;
> - marshallObject(ice.getKey(), out, refMap);
> - marshallObject(ice.getValue(), out, refMap);
> - if (ice.canExpire()) {
> - out.writeBoolean(true);
> - writeUnsignedLong(out, ice.getCreated());
> - out.writeLong(ice.getLifespan()); // could be
> negative so should not use unsigned longs
> - writeUnsignedLong(out, ice.getLastUsed());
> - out.writeLong(ice.getMaxIdle()); // could be
> negative so should not use unsigned longs
> - } else {
> - out.writeBoolean(false);
> - }
> + marshallInternalCacheEntry((InternalCacheEntry) o, out,
> refMap);
> + } else if (o instanceof InternalCacheValue) {
> + marshallInternalCacheValue((InternalCacheValue) o, out,
> refMap);
> } else if (o.getClass().equals(ArrayList.class)) {
> out.writeByte(MAGICNUMBER_ARRAY_LIST);
> marshallCollection((Collection) o, out, refMap);
> @@ -252,7 +256,65 @@
> }
> }
>
> + private void marshallInternalCacheEntry(InternalCacheEntry ice,
> ObjectOutput out, Map<Object, Integer> refMap) throws IOException {
> + if (ice.getClass().equals(ImmortalCacheEntry.class)) {
> + out.writeByte(MAGICNUMBER_ICE_IMMORTAL);
> + marshallObject(ice.getKey(), out, refMap);
> + marshallObject(ice.getValue(), out, refMap);
>
> + } else if (ice.getClass().equals(MortalCacheEntry.class)) {
> + out.writeByte(MAGICNUMBER_ICE_MORTAL);
> + marshallObject(ice.getKey(), out, refMap);
> + marshallObject(ice.getValue(), out, refMap);
> + writeUnsignedLong(out, ice.getCreated());
> + out.writeLong(ice.getLifespan()); // could be negative so
> should not use unsigned longs
> +
> + } else if (ice.getClass().equals(TransientCacheEntry.class)) {
> + out.writeByte(MAGICNUMBER_ICE_TRANSIENT);
> + marshallObject(ice.getKey(), out, refMap);
> + marshallObject(ice.getValue(), out, refMap);
> + writeUnsignedLong(out, ice.getLastUsed());
> + out.writeLong(ice.getMaxIdle()); // could be negative so
> should not use unsigned longs
> +
> + } else if
> (ice.getClass().equals(TransientMortalCacheEntry.class)) {
> + out.writeByte(MAGICNUMBER_ICE_TRANSIENT_MORTAL);
> + marshallObject(ice.getKey(), out, refMap);
> + marshallObject(ice.getValue(), out, refMap);
> + writeUnsignedLong(out, ice.getCreated());
> + out.writeLong(ice.getLifespan()); // could be negative so
> should not use unsigned longs
> + writeUnsignedLong(out, ice.getLastUsed());
> + out.writeLong(ice.getMaxIdle()); // could be negative so
> should not use unsigned longs
> + }
> + }
> +
> + private void marshallInternalCacheValue(InternalCacheValue icv,
> ObjectOutput out, Map<Object, Integer> refMap) throws IOException {
> + if (icv.getClass().equals(ImmortalCacheEntry.class)) {
> + out.writeByte(MAGICNUMBER_ICV_IMMORTAL);
> + marshallObject(icv.getValue(), out, refMap);
> +
> + } else if (icv.getClass().equals(MortalCacheEntry.class)) {
> + out.writeByte(MAGICNUMBER_ICV_MORTAL);
> + marshallObject(icv.getValue(), out, refMap);
> + writeUnsignedLong(out, icv.getCreated());
> + out.writeLong(icv.getLifespan()); // could be negative so
> should not use unsigned longs
> +
> + } else if (icv.getClass().equals(TransientCacheEntry.class)) {
> + out.writeByte(MAGICNUMBER_ICV_TRANSIENT);
> + marshallObject(icv.getValue(), out, refMap);
> + writeUnsignedLong(out, icv.getLastUsed());
> + out.writeLong(icv.getMaxIdle()); // could be negative so
> should not use unsigned longs
> +
> + } else if
> (icv.getClass().equals(TransientMortalCacheEntry.class)) {
> + out.writeByte(MAGICNUMBER_ICV_TRANSIENT_MORTAL);
> + marshallObject(icv.getValue(), out, refMap);
> + writeUnsignedLong(out, icv.getCreated());
> + out.writeLong(icv.getLifespan()); // could be negative so
> should not use unsigned longs
> + writeUnsignedLong(out, icv.getLastUsed());
> + out.writeLong(icv.getMaxIdle()); // could be negative so
> should not use unsigned longs
> + }
> + }
> +
> +
> protected void marshallString(String s, ObjectOutput out) throws
> IOException {
> //StringUtil.saveString(out, s);
> out.writeObject(s);
> @@ -385,19 +447,16 @@
> MarshalledValue mv = new MarshalledValue();
> mv.readExternal(in);
> return mv;
> - case MAGICNUMBER_INTERNAL_CACHED_ENTRY:
> - Object k = unmarshallObject(in, refMap);
> - Object v = unmarshallObject(in, refMap);
> - boolean canExpire = in.readBoolean();
> - if (canExpire) {
> - long created = readUnsignedLong(in);
> - long lifespan = in.readLong(); // could be negative
> so should not use unsigned longs
> - long lastUsed = readUnsignedLong(in);
> - long maxIdle = in.readLong(); // could be negative
> so should not use unsigned longs
> - return InternalEntryFactory.create(k, v, created,
> lifespan, lastUsed, maxIdle);
> - } else {
> - return InternalEntryFactory.create(k, v);
> - }
> + case MAGICNUMBER_ICE_IMMORTAL:
> + case MAGICNUMBER_ICE_MORTAL:
> + case MAGICNUMBER_ICE_TRANSIENT:
> + case MAGICNUMBER_ICE_TRANSIENT_MORTAL:
> + return unmarshallInternalCacheEntry(magicNumber, in,
> refMap);
> + case MAGICNUMBER_ICV_IMMORTAL:
> + case MAGICNUMBER_ICV_MORTAL:
> + case MAGICNUMBER_ICV_TRANSIENT:
> + case MAGICNUMBER_ICV_TRANSIENT_MORTAL:
> + return unmarshallInternalCacheValue(magicNumber, in,
> refMap);
> case MAGICNUMBER_REQUEST_IGNORED_RESPONSE:
> case MAGICNUMBER_EXTENDED_RESPONSE:
> case MAGICNUMBER_EXCEPTION_RESPONSE:
> @@ -465,6 +524,49 @@
> throw new IOException("Unknown magic number " + magicNumber);
> }
>
> + private InternalCacheEntry unmarshallInternalCacheEntry(byte
> magic, ObjectInput in, UnmarshalledReferences refMap) throws
> IOException, ClassNotFoundException {
> + Object k = unmarshallObject(in, refMap);
> + Object v = unmarshallObject(in, refMap);
> + switch (magic) {
> + case MAGICNUMBER_ICE_IMMORTAL:
> + return InternalEntryFactory.create(k, v);
> + case MAGICNUMBER_ICE_MORTAL:
> + return InternalEntryFactory.create(k, v,
> +
> readUnsignedLong(in), (Long) unmarshallObject(in, refMap),
> + -1, -1);
> + case MAGICNUMBER_ICE_TRANSIENT:
> + return InternalEntryFactory.create(k, v,
> + -1, -1,
> +
> readUnsignedLong(in), (Long) unmarshallObject(in, refMap));
> + case MAGICNUMBER_ICE_TRANSIENT_MORTAL:
> + return InternalEntryFactory.create(k, v,
> +
> readUnsignedLong(in), (Long) unmarshallObject(in, refMap),
> +
> readUnsignedLong(in), (Long) unmarshallObject(in, refMap));
> + }
> + throw new IllegalArgumentException("Unknown magic number " +
> magic);
> + }
> +
> + private InternalCacheValue unmarshallInternalCacheValue(byte
> magic, ObjectInput in, UnmarshalledReferences refMap) throws
> IOException, ClassNotFoundException {
> + Object v = unmarshallObject(in, refMap);
> + switch (magic) {
> + case MAGICNUMBER_ICE_IMMORTAL:
> + return InternalEntryFactory.createValue(v);
> + case MAGICNUMBER_ICE_MORTAL:
> + return InternalEntryFactory.createValue(v,
> +
> readUnsignedLong(in), (Long) unmarshallObject(in, refMap),
> + -1, -1);
> + case MAGICNUMBER_ICE_TRANSIENT:
> + return InternalEntryFactory.createValue(v,
> + -1, -1,
> +
> readUnsignedLong(in), (Long) unmarshallObject(in, refMap));
> + case MAGICNUMBER_ICE_TRANSIENT_MORTAL:
> + return InternalEntryFactory.createValue(v,
> +
> readUnsignedLong(in), (Long) unmarshallObject(in, refMap),
> +
> readUnsignedLong(in), (Long) unmarshallObject(in, refMap));
> + }
> + throw new IllegalArgumentException("Unknown magic number " +
> magic);
> + }
> +
> private FastCopyHashMap unmarshallFastCopyHashMap(ObjectInput in,
> UnmarshalledReferences refMap) throws IOException,
> ClassNotFoundException {
> FastCopyHashMap map = new FastCopyHashMap();
> populateFromStream(in, refMap, map);
>
> _______________________________________________
> infinispan-commits mailing list
> infinispan-commits(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-commits
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
17 years
evict
by Mircea Markus
Hi,
There is no comment in code next to "Cache.evict" method regarding its
behavior with respect to transactions and replications.
How should it behave?
While i don't think it should be replicable (we do not want to replicate
the evict process), how do we handle it in the context of Tx? Should we
replicate it and handle it as a remove?
Cheers,
Mircea
17 years, 1 month
