On Jan 28, 2013, at 3:01 PM, Dan Berindei wrote:
>>
>>
>> I originally thought that Infinispan's storeAsBinary can be used for this,
>> but apparently not without some additional changes/tweaks. Maybe we need:
>>
>> 1) A new config option for this behaviour. > /> ?
>> 2) If enabled, maybe
On Jan 28, 2013, at 12:43 PM, Manik Surtani wrote:
>
> On 28 Jan 2013, at 12:35, Dan Berindei wrote:
>
>>
>>
>> On Mon, Jan 28, 2013 at 1:56 PM, Manik Surtani wrote:
>> Let me clarify a few things on this thread. THere seems to be a bit of
>> confusion here. :)
>>
>> storeAsBinary in I
On Jan 28, 2013, at 3:07 PM, Vladimir Blagojevic wrote:
> On 13-01-28 6:56 AM, Manik Surtani wrote:
>>
>> Now lets consider what JSR 107 needs. Similarly named, the feature in JSR
>> 107 serves a completely different purpose, and this is referential
>> integrity. Think database-style isolat
On 13-01-28 6:56 AM, Manik Surtani wrote:
>
> Now lets consider what JSR 107 needs. Similarly named, the feature in JSR
> 107 serves a completely different purpose, and this is referential integrity.
> Think database-style isolation (repeatable read, etc) where concurrent
> threads holding obj
On Mon, Jan 28, 2013 at 2:43 PM, Manik Surtani wrote:
>
> On 28 Jan 2013, at 12:35, Dan Berindei wrote:
>
>
>
> On Mon, Jan 28, 2013 at 1:56 PM, Manik Surtani wrote:
>
>> Let me clarify a few things on this thread. THere seems to be a bit of
>> confusion here. :)
>>
>> storeAsBinary in Infinis
On 28 Jan 2013, at 12:35, Dan Berindei wrote:
>
>
> On Mon, Jan 28, 2013 at 1:56 PM, Manik Surtani wrote:
> Let me clarify a few things on this thread. THere seems to be a bit of
> confusion here. :)
>
> storeAsBinary in Infinispan was designed with the following purposes in mind,
> in o
On Mon, Jan 28, 2013 at 1:56 PM, Manik Surtani wrote:
> Let me clarify a few things on this thread. THere seems to be a bit of
> confusion here. :)
>
> storeAsBinary in Infinispan was designed with the following purposes in
> mind, in order of importance:
>
> 1) Performance. Prevent serialisin
Let me clarify a few things on this thread. THere seems to be a bit of
confusion here. :)
storeAsBinary in Infinispan was designed with the following purposes in mind,
in order of importance:
1) Performance. Prevent serialising/deserializing an entry multiple times
(e.g., to write through t
On 28 Jan 2013, at 09:14, Galder Zamarreño wrote:
> The reason we have storeAsBinary is due to lazyDeserialization. The latter
> was a solution we designed to get around deserialization issues on app server
> environments where JGroups would attempt to deserialize data with the wrong
> classlo
I remember Manik and me pair-programming on that class to simplify it
a bit - especially as there are some performance complexities - but we
ended up not touching it as any change would have violated some
expectations of one feature or another.
Let's put this on the list of cleanups to be performe
On Jan 25, 2013, at 11:37 AM, Sanne Grinovero wrote:
> On 25 January 2013 11:11, Galder Zamarreño wrote:
>>
>> On Jan 24, 2013, at 4:26 PM, Sanne Grinovero wrote:
>>
>>> It's important to note that Infinispan's implementation of storing as
>>> binary isn't guaranteeing different instances of
On 25 January 2013 11:11, Galder Zamarreño wrote:
>
> On Jan 24, 2013, at 4:26 PM, Sanne Grinovero wrote:
>
>> It's important to note that Infinispan's implementation of storing as
>> binary isn't guaranteeing different instances of objects are returned
>> to different get() invocations (especial
On Jan 24, 2013, at 4:26 PM, Sanne Grinovero wrote:
> It's important to note that Infinispan's implementation of storing as
> binary isn't guaranteeing different instances of objects are returned
> to different get() invocations (especially when they happen in
> parallel).
^ Do you have a test
On Jan 24, 2013, at 4:09 PM, Manik Surtani wrote:
>
> On 24 Jan 2013, at 15:39, Vladimir Blagojevic wrote:
>
>> No valid reason Manik. In summary I thought I would have gotten our
>> keys/values serialized even in local VM if I turn on storeAsBinary but that
>> does not seem to be the case.
On 13-01-24 11:26 AM, Sanne Grinovero wrote:
> It's important to note that Infinispan's implementation of storing as
> binary isn't guaranteeing different instances of objects are returned
> to different get() invocations (especially when they happen in
> parallel).
>
> This is the reason for examp
It's important to note that Infinispan's implementation of storing as
binary isn't guaranteeing different instances of objects are returned
to different get() invocations (especially when they happen in
parallel).
This is the reason for example that Hibernate OGM can't use this flag
to have safe a
On 24 Jan 2013, at 15:39, Vladimir Blagojevic wrote:
> No valid reason Manik. In summary I thought I would have gotten our
> keys/values serialized even in local VM if I turn on storeAsBinary but that
> does not seem to be the case.
Is it not? Perhaps it is only serialised the first time a s
No valid reason Manik. In summary I thought I would have gotten our
keys/values serialized even in local VM if I turn on storeAsBinary but
that does not seem to be the case. I need to use storeAsBinary to
complete a feature of JSR 107 that allows storing of key/value pairs as
serialized values
18 matches
Mail list logo
