On Saturday, March 1, 2014 8:57:37 AM UTC-8, Nels Nelson wrote: > > On Saturday, March 1, 2014 12:03:07 AM UTC-6, Jeremy Evans wrote: >> >> This might be due to tactical_eager_loading, single_table_inheritance, >> eager_each, or some combination of those plugins, but obviously I'll need >> to be able to reproduce it to debug it. How are you running that code in a >> multi-threaded environment? I don't see it starting any threads. Are you >> able to reproduce it just by running it? >> > > No, I am not able to reproduce it in a single-threaded environment. I am > barely able to reproduce it in a multi-threaded environment. > > I tried a variety of measures to attempt to ensure that this error stopped > happening, including wrapping access to things like Object#tags invocations > with Mutex locks, and also manually caching the result of tags (kludgy) in > case the invocation of tags was invoking selects on the rows (manual caches > get nilled out on updates, of course). Nothing seemed to do the trick, > though the caching seemed to decrease its frequency, of course. (But even > that was discouraging, since I had already activated the sequel caching > plugin for all models -- Sequel::Model.plugin :caching, > java.util.concurrent.ConcurrentHashMap.new.) >
Sequel is designed to be thread-safe (see http://sequel.jeremyevans.net/rdoc/files/doc/thread_safety_rdoc.html), so you shouldn't have to use manual mutexes (unless you are dealing with the exceptions mentioned in that guide). If there is a concurrency issue, I definitely want to fix it. The last reported one was related to prepared statements and was fixed in 3.47.0, so they are fairly rare. > The code is running in a heavily multi-threaded environment accepting user > requests from multiple remote connections, all of which then interact with > the same routines, but shared memory is kept to a minimum. > > The rest of the request handling code is a bit spaghetti, so I did not > include it in the given example. I had hoped that indicating that the > provided code example was running in a multi-threaded environment would > have been sufficient, though, it is certainly expected that such code would > greatly complicate the trivial example provided. > The example needs to be completely self contained, in that I can run it to reproduce the error (or in the case of non-determinism, I can run it in a loop until it errors). Is it possible for you to reproduce the error using the example code you posted? > Also, just FYI, you don't need to require 'jdbc-postgres' or set >> Sequel::Model.db manually. Also, your tagged association (which you don't >> appear to be using), needs to use a :key_method option, since object_id is >> an existing ruby method. Finally, Model#save returns self, so you don't >> need to return self explicitly in tag and untag. >> > > Thank you, this is nice to know. I tried to remove gem 'jdbc-postgres' > from the example, and it still works; however when I remove it from my main > program, it fails: > > Sequel::AdapterNotFound: LoadError: no such file to load -- > sequel/adapters/postgresql > How are you connecting in your main program? Are you calling Sequel.connect with a URL? > One last thing, I'm having trouble finding documentation on the usage of > the :key_method option. Do you happen to have a link? > http://sequel.jeremyevans.net/rdoc/files/doc/association_basics_rdoc.html, look under Column Naming Conflict Options. Thanks, Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/groups/opt_out.
