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 <emman...@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 flushes ? >>> I will open a JIRA about this point if it has not already been done. >>> >>> Guillaume >>> >>> 2012/4/25 Emmanuel Bernard <emman...@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 better results? >>> >>> 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 problems. >>> >>> I have found this blog entry to be quite insightful >>> http://blog.pythonisito.com/2011/12/mongodbs-write-lock.html >>> >>> Generally speaking, if all data can stay in memory, MongoDB should behave >>> wonderfully. >>> >>> 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. >>> >>> Emmanuel >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
