It would be a loss of functionality.
As a common example, the AS web session replication cache is configured
for ASYNC by default, for performance reasons.
But it can be changed to SYNC to guarantee that when the request
finishes that the session was replicated.
That wouldn't be possible if you
On 01/30/2014 08:51 PM, Mircea Markus wrote:
> On Jan 30, 2014, at 9:42 AM, Galder Zamarreño wrote:
>
>> On Jan 21, 2014, at 11:52 PM, Mircea Markus wrote:
>>
>>> On Jan 15, 2014, at 1:42 PM, Emmanuel Bernard
>>> wrote:
>>>
By the way, people looking for that feature are also asking for a
Hi all,
The following came to my mind yesterday: I think we should ditch ASYNC modes
for DIST/REPL/INV and our async cache store functionality.
Instead, whoever wants to store something asyncronously should use asynchronous
methods, i.e. call putAsync. So, this would mean that when you call put
On Jan 30, 2014, at 9:42 AM, Galder Zamarreño wrote:
>
> On Jan 21, 2014, at 11:52 PM, Mircea Markus wrote:
>
>>
>> On Jan 15, 2014, at 1:42 PM, Emmanuel Bernard wrote:
>>
>>> By the way, people looking for that feature are also asking for a unified
>>> Cache API accessing these several c
On Jan 29, 2014, at 12:05 AM, Sanne Grinovero wrote:
> Hi all,
> can I hope for a release to happen soon?
>
> I am needing releases to happen more frequently, or the various
> cross-project integrations can't evolve.
+1. We have quite some pending things to integrate. I'll update the release
Hi list!
I've been pondering about re-using the marshalling machinery of
Infinispan in another project, specifically in ProtoStream, where I'm
planning to add it as a test scoped dependency so I can create a
benchmark to compare marshalling performace. I'm basically interested
in comparing Pr
Hi,
as I am upgrading the JPA Store to work with Infinispan 6.0 SPI, there
have been several ideas/recommendations to use Hibernate-specific API
[1][2]. Currently, the code uses javax.persistence.* stuff only
(although it uses on hibernate implemenation).
What do you think, should we:
a) stay
On Jan 21, 2014, at 11:52 PM, Mircea Markus wrote:
>
> On Jan 15, 2014, at 1:42 PM, Emmanuel Bernard wrote:
>
>> By the way, people looking for that feature are also asking for a unified
>> Cache API accessing these several caches right? Otherwise I am not fully
>> understanding why they as
