Oh wait, I guess I see. There is no per-model identity map -- all identity_maps reference the same Thread variable, so it wouldn't make a difference if I used a single global CHM instead (other than the intended consequence of integrating the currently thread-segregated maps).
On Apr 5, 10:38 pm, Nels Nelson <[email protected]> wrote: > So, since I've been developing my application in JRuby, could I not > just leverage the JDK's ConcurrentHashMap? > > Would I have to do more than simply assign an instance of a CHM to a > constant in my application, and then monkey-patch the > Sequel::Plugins::IdentityMap::ClassMethods#identity_map accessor > methods to refer to my application constant instead of the > Thread.current[:sequel_identity_map]? > > Clearly I wouldn't be able to re-assign the constant without a bit of > warning silencing, so I'm unsure how I might go about taking care of a > per-model identity map, unless I were to have nested CHMs keyed by > model. May I ask for your thoughts on this, Jeremy? > > Thanks for any attention you can give my questions, Jeremy. > -Nels > > On Mar 2, 10:19 am, Jeremy Evans <[email protected]> wrote: > > > > > > > > > On Thursday, March 1, 2012 8:22:08 PM UTC-8, Nels Nelson wrote: > > > > I guess I simply cannot do what I am attempting to do. > > > > I re-forked the fork that you made, and made some adjustments to > > > reflect what I am actually attempting to do. > > > >https://gist.github.com/1955486 > > > > The non-persistent items (the string "Hi!" in this case) are simply > > > not there in the second thread. > > > > Still, thank you for your help, Jeremy. I guess I will have to figure > > > out how to create a thread safe hash that I store as a class variable > > > somewhere, and key by entity instance or something. That just seems > > > awful. > > > You could try just make the change to the identity_map plugin to use a > > thread-safe global hash instead of a regular hash stored in a thread-local > > variable (changing identity_map and identity_map=). But you are going to > > have to use some sort of locking mechanism at the model instance level to > > make sure that no thread is modifying an instance while another thread is > > operating on it. I'd recommend writing a mutex plugin so you can do > > model_instance.sync{...} for that. > > > Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
