Invocation and transaction contexts
by Manik Surtani
Picking up from a few q's Mircea asked on IRC earlier while I was away:
> mmarkus:manik, I understand your point with that
> mmarkus:What I wanted to say is to have to implementations of
> InvocationContext interface, TxInvocationContext and
> NonTxInvocationContext
> mmarkus:the code from GetKeyValueCommand would look the same, only
> difference is that at runtime it works with different
> implementations, depending on weather it runs in a tx context or not
So a quick recap for those who missed the conversation on IRC:
InvocationContext (IC) and TransactionContext (TC) are interfaces that
both extend EntryLookup and FlagContainer.
This is so that entries wrapped for MVCC guarantees (as
RepeatableReadEntries or ReadCommittedEntries) are stored in the
context. Also, optional Flags, such as forcing local mode, are also
stored in the context. The reason why we have 2 different types of
contexts is that if the call is transactional, some of this needs to
be available for the duration of the entire transaction.
To enable transparent switching between the appropriate context in
use, implementations of methods on EntryLookup in the IC checks a TC
first, e.g.,
@Override
public CacheEntry lookupEntry(Object k) {
if (transactionContext != null) {
return transactionContext.lookupEntry(k);
} else {
return lookedUpEntries == null ? null :
lookedUpEntries.get(k);
}
}
Mircea, so from what I gather, you're proposing 2 separate IC impls,
one that does this check-and-delegate and one that does not, and the
appropriate one is set up by the InvocationContextInterceptor (ICI).
While this does make sense, unfortunately ICs are built much earlier,
in the CacheDelegate, Notifier (when isolating contexts for
callbacks), or the CommandAwareRpcDispatcher (for inbound calls over
the network). This is before we are aware of the presence of absence
of any transactions which may be in scope.
The other possibility is for the ICI to copy a non-tx-aware IC to a tx-
aware one. But IMO the construction and copy will outweigh the cost
of the if block and the relative code ugliness.
Maybe there is another way, perhaps I have missed something?
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
16 years, 5 months
HitchHikerExecutor
by Manik Surtani
This is something Adrian came up with while on IRC yesterday:
https://jira.jboss.org/jira/browse/ISPN-58
This is an executor that does not spawn new threads, but instead
queues up tasks, adds an interceptor to the chain, and "hijacks"
process threads to execute queued runnables.
The purpose of this is so that Infinispan plays nice in runtimes that
restrict the spawning of threads, such as Google's App Engine.
I added this as a JIRA for now, but after sleeping on it, I think this
is unnecessary. In-process executors could be used for now, utilising
the caller thread to execute the runnable, and in future GAE-specific
executors to delegate to the upcoming Task Queue API [1]. In fact,
this could be a part of a GAE compatibility module which may include a
cache store that uses the app engine data store, possibly via JPA [2].
WDYT?
Cheers
Manik
[1] http://code.google.com/p/googleappengine/issues/detail?id=109
[2] http://code.google.com/appengine/docs/java/datastore/usingjpa.html
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
16 years, 5 months
First version of JBoss Marshalling based Marshaller
by Galder Zamarreno
Hi,
Re: https://jira.jboss.org/jira/browse/ISPN-44
I've attached a patch to the JIRA containing a 1st implementation of a
JBoss Marshalling based marshalling layer for Infinispan. A few notes:
- JBMAR based marshalling is optional for the moment. To enable it,
configure the marshaller to be
org.infinispan.marshall.jboss.JBossMarshaller.
- I created a new profile that runs the testsuite with this marshaller.
To run, just do: mvn -Ptest-jbossmarshaller test.
- I've run the testsuite for core and there're no regressions with new
marshaller. I also wanted to test jdbc but the testsuite seems to need a
bit of tidying up or I need to preconfigure something (Tests run: 177,
Failures: 4, Errors: 0, Skipped: 164, Time elapsed: 0.631 sec <<<
FAILURE!). Regardless, jdbc uses a dummy marshaller so would be
pointless for the moment.
- Different type marshalling has been implemented using
org.jboss.marshalling.Externalizer implementations mapped from
HorizonMarshaller class. JBMAR does support Externalizable classes but I
figured it out later and wanted to touch as less of existing code as
possible. So, for Beta1, some of Externalizer implementations (except
JDK classes) will probably go in favour of Externalizable implementations.
- StateTransferManagerImpl uses marshaller in a different way to the
rest. It first opens an ObjectOutput and then makes multiple calls to
stream stuff. StateTransferManagerImpl was hardcoded to use OOS and OIS
so I had to add org.infinispan.marshall.Marshaller that would
start/finish these OO/OI implementations. This is to enable
JBossMarshaller to provide OO/OI implementations coming from JBMAR.
- I had one doubt about the scope of the marshaller. I gave it
@Scope(Scopes.GLOBAL) since it'd be something shared among all caches.
Now, I assume its @Stop method would be called when all caches are
finished and the CacheManager is stopped? Wanted to make sure nothing is
leaked!.
- Application level versioning (VAM) is not yet supported in JBMAR but
David is happy to listen for ideas. I'll address that for Beta1.
- For Beta1, I'd like David to have a look at what I've done and see if
he can review it and then do perf tests to see whether this new
implementation is faster than our current one. If it is, next step would
be to design a way for people to extend/modify via configuration magic
numbers for their classes, provide Externalizers for their own
classes...etc.
Cheers,
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
16 years, 5 months
BucketBasedCacheStore#loadBucket does not set the bucketName
by Adrian Cole
When in BucketBasedCacheStore.removeLockSafe, the following is called:
Bucket bucket = loadBucket(keyHashCodeStr);
now, the bucket returned does not always have its name set (at least
in the BaseCacheStoreTest:402)
I would suggest to either enforce bucket's immutable name field, or
ensure it is set on all options. Otherwise, all cachestore
implementations have to check this individually.
WDYT?
-Adrian
16 years, 6 months
explicit distributed locking WAS: serializable isolation level
by Manik Surtani
I've created a JIRA for explicit distributed locking with some
preliminary notes.
https://jira.jboss.org/jira/browse/ISPN-48
Cheers
Manik
On 7 Apr 2009, at 15:51, Jason T. Greene wrote:
> Mircea Markus wrote:
>> Hi,
>> As we do support serializable isolation level in horizon, a an
>> approach for supporting certain amount of concurrency is by using
>> an optimistic concurrency control strategy (this is the way Oracle
>> implements it).
>> This way we still allow a degree of concurrency, also maintaining
>> the 'serializable' semantics.
>
> It's funny that you mention that, as Oracle is known for getting
> Serializable wrong. If someone is using Serializable, they can't
> design a concurrent app, and they dont care about performance.
>
> Instead, if people need explicit serialization semantics, they
> should be using write-locks on a read. You can do this today by
> writing to a bogus attribute. However, a lock() method which
> supports eager and lazy (eager = aquire lock on the cluster now,
> lazy = aquire it as part of repl like today) locking would be more
> efficient and intuitive.
>
> Example:
>
> cache.lock(total-cash);
> sum = // calculate new total
> cache.put(total-cash, sum);
>
> --
> Jason T. Greene
> JBoss, a division of Red Hat
> _______________________________________________
> horizon-dev mailing list
> horizon-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/horizon-dev
--
Manik Surtani
manik(a)jboss.org
Lead, JBoss Cache
http://www.jbosscache.org
16 years, 6 months
Re: [infinispan-dev] serializable isolation level
by Manik Surtani
On 8 Apr 2009, at 08:46, Mircea Markus wrote:
> Manik Surtani wrote:
>>
>> On 7 Apr 2009, at 19:10, Mircea Markus wrote:
>>
>>>
>>> These are 4 isolation defined by ANSI, but as we do not support
>>> all of them, we should not allow users to specify them. What's the
>>> advantage for a user to be able to specify "SERIALIZABLE" and the
>>> system to automatically switch to REPETABLE_READ, i.e. in which
>>> scenario would one want to do that?
>>
>> Compatibility with JBC.
> Migration script is the place then.
>> Easy migration of configuration values. Unless you want to handle
>> the upgrading/downgrading in a migration script. :-) Which is
>> also OK by me.
> Fine by me. Is there such a script?
https://jira.jboss.org/jira/browse/ISPN-37
Want to take this on? You're the resident XSLT expert after all. ;)
--
Manik Surtani
manik(a)jboss.org
Lead, JBoss Cache
http://www.jbosscache.org
16 years, 6 months
Re: [horizon-dev] serializable isolation level
by Manik Surtani
On 7 Apr 2009, at 19:10, Mircea Markus wrote:
>
> These are 4 isolation defined by ANSI, but as we do not support all
> of them, we should not allow users to specify them. What's the
> advantage for a user to be able to specify "SERIALIZABLE" and the
> system to automatically switch to REPETABLE_READ, i.e. in which
> scenario would one want to do that?
Compatibility with JBC. Easy migration of configuration values.
Unless you want to handle the upgrading/downgrading in a migration
script. :-) Which is also OK by me.
> [1] states that : "Most DBMSs offer *a number* of /transaction
> isolation levels/ which control the degree of locking which occurs
> when selecting data" so not all DBMS support all isolation levels.
> (e,g, oracle does not support NONE and READ_UNCOMMITTED, DB2 does
> not support READ_UNCOMMITTED as well [2]).
--
Manik Surtani
manik(a)jboss.org
Lead, JBoss Cache
http://www.jbosscache.org
16 years, 6 months
