5.2 XML schema
by Tristan Tarrant
Hi all,
as part of my work on ISPN-1978 [1] and ISPN-2210 [2], I have hit a snag
with the XML schema and the extensibility I want to allow:
- currently elements in the global and cache configuration can be placed
in any order and can happen at most once (using the <xs:all /> element)
- I want to add an <xs:any namespace="##other /> element to the <xs:all
/> above, but this is not allowed in XMLSchema 1.0. It is however a
valid construct in XMLSchema 1.1
- Eclipse (even the latest Juno) does not validate XMLSchema 1.1 files
and therefore developers using it wouldn't be able to get content assist
when editing Infinispan configuration files
Possible solutions:
- I go with a 1.1 schema, telling Eclipse users to pressure for an
updated XML editor
- I stay with a 1.0 schema, but swap <xs:all> with <xs:sequence>, which
forces the elements to appear in a specific order (minus), but allows
extension points to be treated as first-class citizens (plus)
- I stay with a 1.0 schema, and place the extension points inside a
<modules> element which can be a child of <global>, <default> and
<namedCache>. This allows elements to be in any order, but adds the
extra indirection.
Fortunately we don't have this issue with the cache stores since that is
a <xs:sequence>.
Opinions ?
Tristan
[1] https://issues.jboss.org/browse/ISPN-1978
[2] https://issues.jboss.org/browse/ISPN-2210
14 years
Put Command
by Meena Rajani
Hi
I am modifying cache with freshness and consistency parameters for QoS.
I want to know how an update to a database is done when cache is in
invalidation mode and when it is in replication mode(both sync, async) Can
some one please send me a simple algorithm of an update/modification
Infinispan in Invalidation Mode
when I want to insert/modify some data with ejb entity,
1 Does it invalidate data in the cache and then goes to the database and
update over there?
Infinispan in Replication Mode
when I want to insert/modify some data with ejb entity,
2. Does it replicate data(in local and Across the cluster ) and then update
the data to the database? what happens in case of failure.
Thanks
Meena Rajani
14 years
We have 10 pull reqs outstanding...
by Galder Zamarreño
Barring the ones marked as deferred (in the title)…
So, let's get cracking :)
If you're taking any, note it in the assignment field. If there're already assigned to someone, leave it to them.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years
Cache Loaders configuration dilemma
by Tristan Tarrant
Hi guys,
as part of ISPN-1978, I'm migrating the Cache Loaders to the new
configuration builder APIs. I want to change the init() method of the
CacheLoaders which has the following signature
public void init(CacheLoaderConfig config, Cache<?, ?> cache,
StreamingMarshaller m) throws CacheLoaderException
to the following:
public void init(AbstractLoaderConfiguration config, Cache<?, ?> cache,
StreamingMarshaller m) throws CacheLoaderException
This will break all existing cache loaders/stores: I'll fix all the ones
bundled in the distribution, but do we need to provide compatibility
with third party loaders ?
Tristan
14 years
Issue about propagation of the RollbackCommand in Infinispan 5.2.0
by Sebastiano Peluso
Hi all,
I have a question about the propagation of the RollbackCommand in
Infinispan 5.2.0 when I use the Optimistic locking scheme and the
Distribution clustering mode.
In particular I have noticed that a RollbackCommand command for a
transaction T is propagated on a set of nodes S even if T's coordinator
has never sent and it will never send a PrepareCommand command to nodes
in S.
I try to make clear the issue by the following example.
Suppose you have a transaction T executing on node N0 and T writes on
keys k0, k1, k2,...., km (m+1 keys) until it reaches the prepare phase.
In addition node Ni, with i=0,...,m+1, is the ki's primary owner. If at
prepare time, during the lock acquisition on the local node N0 (see
visitPrepareCommand method in OptimisticLockingInterceptor class) T
fails to acquire the lock on k0, an exception is thrown (e.g.
TimeoutException) and T will be rolled back. In this case, when T starts
the rollback phase, it seems to me that a RollbackCommand command is
multicast to all nodes Nj, with j=1,...,d, if k0 is sorted after kj
during the local lock acquisition (see acquireAllLocks method in
OptimisticLockingInterceptor), because:
- shouldInvokeRemoteCommand method on the TxInvocationContext returns
true (see BaseRpcInterceptor class);
- getAffectedKeys on the TxInvocationContext returns the set {k1,...,
kd} (see visitRollbackCommand in DistributionInterceptor class).
Is it correct?
If I'm not wrong, which is the design choice behind this implementation?
Thank you.
Best regards,
Sebastiano Peluso
--
Sebastiano Peluso, PhD student
Department of Computer, Control and Management Engineering
Sapienza University of Rome
Via Ariosto 25, 00185, Rome, Italy
Tel. +39 06 77274108
Webpage http://www.dis.uniroma1.it/~peluso
Distributed Systems Group, INESC-ID
Instituto Superior Técnico
Rua Alves Redol 9, 1000-029, Lisbon, Portugal
Webpage http://www.gsd.inesc-id.pt/~peluso
14 years
NBST design
by Adrian Nistor
Hi,
I managed to rewrite the old NBST design document and created a v2 [1]
that should cover the interesting aspects. I'm not sure I managed to
make it intelligible and sound enough, but this is the best I could do
after several attempts at rewriting :)
Please read it. Your feedback is welcome!
The old document is still there [2] for now but should not be relied
upon. I kept it because some parts of it might still be relevant and
could be moved to v2 doc, but I don't think they are essential in
understading the code of our pull request. Dan, could you have a look if
there are any bits that we need to move to v2?
Thanks,
Adrian
[1] https://community.jboss.org/wiki/Non-BlockingStateTransferV2
[2] https://community.jboss.org/wiki/Non-blockingStateTransfer
14 years
