On Jan 31, 2014, at 7:30 AM, Radim Vansa rva...@redhat.com wrote:
On 01/30/2014 08:51 PM, Mircea Markus wrote:
On Jan 30, 2014, at 9:42 AM, Galder Zamarreño gal...@redhat.com wrote:
On Jan 21, 2014, at 11:52 PM, Mircea Markus mmar...@redhat.com wrote:
On Jan 15, 2014, at 1:42 PM,
Couldn't this be handled higher up in our implementatoin then ?
If I enable an async mode, all puts / gets become putAsync/getAsync
transparently to both the application and to the state transfer.
Tristan
On 01/31/2014 08:32 AM, Dennis Reed wrote:
It would be a loss of functionality.
As a
Generally I like the systems designed with SYNC_DIST + async shared cachestore.
It's probably the best setup we can offer:
- you need a shared cachestore for persistence consistency
- using SYNC distribution to other replicas provides a fairly decent resilience
- if your cachestore needs to be
+1 to moving to the async methods only. I have mentioned this as well
in passing when discussing L1 as there is no way to ensure consistency
with an async transport. Although if we fire the async methods with
either SKIP_REMOTE_LOOKUP/IGNORE_RETURN_VALUES flag than this
consistency is still lost
+1 on b without renaming.
The fact that we're using Hibernate is an implementation detail, I
think we should focus on the user contract: the end user is supposed
to provide annotated entities.
The user is free to use JPA annotations only in his mapping, so I
think the name is not too bad.
Still
On Jan 31, 2014, at 1:44 PM, Sanne Grinovero sa...@infinispan.org wrote:
+1 on b without renaming.
The fact that we're using Hibernate is an implementation detail, I
think we should focus on the user contract: the end user is supposed
to provide annotated entities.
The user is free to
Not 100% related to what you are asking about but have a look at this
post and the discussion that erupted:
http://gridgain.blogspot.ca/2012/12/java-serialization-good-fast-and-faster.html
Vladimir
On 1/30/2014, 7:13 AM, Adrian Nistor wrote:
Hi list!
I've been pondering about re-using the
Changing the subject, as Adrian will need a reply to his (more
important) question.
I don't think we should go shopping for different marshaller
implementations, especially given other priorities.
I've been keeping an eye on Kryo since a while and it looks very good
indeed, but JBMarshaller is
Thanks Vladimir! It's a really fun and interesting discussion going on
there :)
On 01/31/2014 06:29 PM, Vladimir Blagojevic wrote:
Not 100% related to what you are asking about but have a look at this
post and the discussion that erupted:
Indeed, I'm not looking for a JBMAR replacement, just trying to create a
comparative benchmark between it and Protobuf/ProtoStream.
I'm trying to make an apple to apple comparison by marshalling the same
domain model with both libraries. My (incipient) test currently
indicates a 2x better
10 matches
Mail list logo
