But you still need the collect and the event to release it.
On 25 avr. 2012, at 10:59, Sanne Grinovero wrote:
Isn't Hibernate ORM already providing such a service via the
Session/Persistence context/"L1" container ?
We might be able to take advantage of existing events to control the
batching on MongoDB.
On 25 April 2012 08:35, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
> I don't think we need an actual multi threaded cache. the flush operation in
Hibernate is not multi threaded, neither is the session.
> A simple Map (or a better append only structure) will suffice, I think.
> On 25 avr. 2012, at 09:32, Guillaume SCHEIBEL wrote:
>> Hi all,
>> What do you think about using the Ehcache module to store the data between 2
>> I will open a JIRA about this point if it has not already been done.
>> 2012/4/25 Emmanuel Bernard <emmanuel(a)hibernate.org>
>> Hi Alan and all,
>> I have been researching the spikes issue you encounter in the stress test from a
theoretical point of view.
>> You were trying a different associations storage approach (splitting associations
as one row per document rather than the whole association per document). Does that return
>> I am skeptical for a few reasons. MongoDB has a global write lock per mongod
process (they are working on a more fine grained solution). So if the spikes are due to
lock contention, shuffling data won't help much. Also make sure you use MongoDB 2.0
instead of 1.8 as they yield lock on page fault which should solve a lot of these spikes
>> I have found this blog entry to be quite insightful
>> Generally speaking, if all data can stay in memory, MongoDB should behave
>> Which leads to my demo and the time difference between Infinispan 5s and Mongodb
20s. I can see several reasons:
>> - we don't really batch operations in the mongodb dialect and we should.
>> We should accumulate operations and apply them at the end of the flush operation
in one batch. That will require some new infrastructure from OGM's engine though
>> to tell the dialect when to "flush".
>> - my VM might swap memory on disk which would explain the difference
>> - or it could be that Infinispan is simply 4 times faster which would not be too
surprising as Infinispan is in-process.
>> hibernate-dev mailing list
> hibernate-dev mailing list