I guess this is a somehow a bug or typo.
Transactions and stores are two separate concepts. While it sounds to
flush to normal store at the TX commit but when one knowingly sets
store as async, he accepts the risk of consistence in favor of speed.
I expect this to be fixed (or at least discussed) before GA.
Amin
On Sat, Jan 23, 2010 at 3:48 PM, Philippe Van Dyck <pvdyck(a)gmail.com> wrote:
I do confirm this behavior.
Transactions and asynchronous updates may seem antagonistic, but they are
not on a multi-level cache.
I plan to use a synchronous transactional disk cache and a second non
transactional asynchronous s3 cache, to get the best of both worlds.
Since the asynchronous aspect of the s3 cache will not allow me to get any
feedback (aka Future), I want it to 'write-behind' in the background (and
hope everything goes well).
I will wait for the qi4j v1 release (probably Monday), adapt infinispan to
the blobstore of jClouds and take a closer look at this in a couple of
weeks.
Phil
On Sat, Jan 23, 2010 at 12:58 PM, Amin Abbaspour <a.abbaspour(a)gmail.com>
wrote:
>
> Hi All,
>
> Regarding
>
http://community.jboss.org/wiki/Write-ThroughAndWrite-BehindCaching
> , Even if Syncer is in Async mode, but if we modify a key inside a
> transaction boundary it is always stored synchronously! Why is it so?
> How can I have both locking and async store. FYI I use JBossTM
> Standalone.
>
> Regards,
> Amin Abbaspour
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev