Re: [horizon-dev] serializable isolation level
by Manik Surtani
NOTE: CC'ing infinispan-dev(a)lists.jboss.org instead of horizon-dev(a)lists.jboss.org
Comments inline:
On 7 Apr 2009, at 15:35, Mircea Markus wrote:
> Manik Surtani wrote:
>>
>> On 7 Apr 2009, at 15:07, Mircea Markus wrote:
>>
>>> Hi,
>>>
>>> As we do support serializable isolation level in horizon
>>
>> No we don't. See the javadocs on the IsolationLevel enum.
> Why are we even allowing a used to specify a SERIALIZABLE isolation
> level if we simply do not support it? I can see most of the users
> not reading the javadocs, and will be unpleased when seeing that a
> phanthom read occurred, even though he/she specified SERIALIZABLE -
> bad experience.
They are allowed to set what they like. Setting any old gibberish
throws a ConfigurationException, while setting a valid isolation level
defined by the ANSI standard for ACIDity [1] is respected, but is
either upgraded or downgraded to an isolation level we support (which
is READ_COMMITTED and REPEATABLE_READ). Appropriate WARNings are
logged if an upgrade or downgrade takes place so IMO this isn't a bad
user experience. We state almost everywhere that we only support R_C
and R_R. If anyone expects to configure SERIALIZABLE, *not* look at
the logs, and then expect things to work, well that's his problem. :-)
[1] http://en.wikipedia.org/wiki/Isolation_%28database_systems%29
--
Manik Surtani
manik(a)jboss.org
Lead, JBoss Cache
http://www.jbosscache.org
17 years, 1 month
heuristic transactions & failure recovery
by Mircea Markus
Hi,
Current implementation of tx in JBC/infinispan might result in heuristic
transactions: e.g. if the coordinator cannot send an commit message (2nd
phase from 2PC) within a given timeout to some of the participants, this
might results in data being committed on some nodes and rollbacked on
other. Even worse, there is no way to take action and recover from the
failure. Would it make sense to have tx failure recovery mechanism in
infinispan? I'm referring here to something similar to the way DBs work,
i.e. based on an persistent tx logs, external notifications etc? Even
though I didn't see any such request on forums, I guess such a feature
is mandatory for certain systems, e.g. a financial application. Wdyt?
Cheers,
Mircea
17 years, 1 month
tx optimizations
by Mircea Markus
Hi,
Here are two optimizations that can be implemented in our 2PC model:
1) if there are only two members int the cluster use an 1PC (or if you
only replicate to one buddy, like in buddy replication). If the 1st
phase fails remotely, then also rollback locally. This would reduce one
network roundtrip.
2) when asked to prepare, a participant might return a value indicating
that no changes were made (read-only participant), so this one won't
need an commit message, so less roundtrip.
Wdyt?
Cheers,
Mircea
17 years, 1 month
SVN freeze
by Manik Surtani
Due to some SVN maint work, we need to freeze the repo effective
immediately. Please do not commit any changes from now on otherwise
they may be lost.
Cheers
--
Manik Surtani
Lead, JBoss Cache
http://www.jbosscache.org
manik(a)jboss.org
17 years, 1 month
The meaning of "concurrency level"
by Manik Surtani
This is an attribute in the <locking /> configuration element and is
used to define the number of lock stripes used by the LockManager,
*if* striped locking is used.
Now I wonder whether we need a tuning parameter of this sort in the
data container as well. Consider that the SimpleDataContainer is
backed by a CHM and the FIFO and LRU variants are backed by something
very similar to a CHM (in that there are lockable segments which
contain hash tables). In both cases, I use default concurrency levels
(16 segments), but maybe this should be configurable too? Should this
be a separate attribute, or could "concurrencyLevel" be reused here?
The way I see it, LockManager needs a higher number of stripes since
transactions could span keys that are in > 1 stripe. Segments,
however, are only locked for the duration of a write access to the
container which is a) typically very short and b) usually limited to
the number of active threads, which is related to the number of cores/
CPUs.
Basically, what I am saying is that the latter could probably be
guessed/hard coded rather than made configurable, and even if made
configurable, is unlikely to be the same as the number of stripes used
by the LockManager.
Thoughts/comments?
--
Manik Surtani
Lead, JBoss Cache
http://www.jbosscache.org
manik(a)jboss.org
17 years, 1 month
surefire versions
by Mircea Markus
Hi,
When using surefire plugin version 2.4.3 there are some issues with test
reports: reports are missing test class name.
I've noticed that there is another surefire version - "2.4.3-JBOSS" -
reports work fine with this version.
Is there a fix for the above issue in some JBoss-version-of-surefire?
What's the deal with "2.4.3-JBOSS"?
According to codehaus, the report issue should had been fixed in 2.4.1
(http://jira.codehaus.org/browse/SUREFIRE-433), but it might be that the
fix does not work for our setup (i.e. parallel suite at test level, each
class being a test).
Cheers,
Mircea
17 years, 1 month
ReplicateCommand
by Mircea Markus
Hi,
Some thought on ReplicateCommand.
It is also used to replicate a single command, which is inefficient, as
2 objects are unnecessarily created: the ReplicateCommand itself and an
array holding only one object.
Why not replicated the aggregated command directly?
Another thing about the name: even though it is correct, it sounds very
much like ReplicableCommand. I suggest renaming to CompositeCommand, or
ContainerCommand.
wdyt?
Cheers,
Mircea
17 years, 1 month
Maven structure
by Manik Surtani
This stems from a discussion Adrian and I had about the maven module
structure for Infinispan and how it could change to be more modular.
/pom.xml <-- parent POM, used to build/test the entire project
/project <- project details such as team and common factors across all
modules (Artifact Id: infinispan-project)
/distribution <-- aggregator POM to build a complete and coherent
distribution (Artifact Id: infinispan-distribution)
/core <-- core code + tests. (Artifact Id: infinispan-core)
/cachestore/* <-- several sub-modules here, for cache stores that have
external dependencies. Such as JDBC, BDBJE, S3 so that external
dependencies can be mapped separately. Typical artifact ids: infinispan-
cachestore-bdbje
/tree <-- for the tree cache API (Artifact Id: infinispan-tree)
/fine-grained <-- for the fine-grained API (Artifact Id: infinispan-fine-
grained)
Any thoughts/comments/suggestions on the above?
Cheers
--
Manik Surtani
Lead, JBoss Cache
http://www.jbosscache.org
manik(a)jboss.org
17 years, 1 month
Disabled tests
by Manik Surtani
So these are the tests currently disabled in trunk:
Gemini:trunk manik$ grep -R "Test.*enabled[ ]*=[ ]*false" * | grep -
v .svn | sed -e "s/:.*//"
src/test/java/org/infinispan/loader/jdbc/PooledConnectionFactoryTest.java
src/test/java/org/infinispan/loader/s3/S3CacheStoreIntegrationTest.java
src/test/java/org/infinispan/profiling/AbstractProfileTest.java
src/test/java/org/infinispan/profiling/MemConsumptionTest.java
src/test/java/org/infinispan/profiling/ProfileTest.java
src/test/java/org/infinispan/profiling/ProfileTest.java
src/test/java/org/infinispan/profiling/ProfileTest.java
src/test/java/org/infinispan/profiling/ProfileTestSlave.java
src/test/java/org/infinispan/profiling/TreeProfileTest.java
src/test/java/org/infinispan/test/fwk/TestNameVerifier.java
I think the only relevant ones are:
src/test/java/org/infinispan/loader/jdbc/PooledConnectionFactoryTest.java
src/test/java/org/infinispan/loader/s3/S3CacheStoreIntegrationTest.java
Mircea and Adrian - these are yours, I believe?
Cheers
--
Manik Surtani
Lead, JBoss Cache
http://www.jbosscache.org
manik(a)jboss.org
17 years, 1 month
