--- Log opened Sun Jun 17 00:00:02 2012
06:21 < conseo> mcallan: i think it is a mistake to synchronize around votoorla.g.sql.Database in the tables to contain the Connection object: http://stackoverflow.com/questions/2713407/is-this-use-of-preparedstatements-in-a-thread-in-java-correct
06:21 < conseo> better would be to simply return a new connection for each request and close it, this gives thread safety and allows us to access the DB from multiple threads
08:20 < conseo> (in parallel)
11:10 < mcallan> i think they wrong, c.  thread safety varies with the driver.  you have to read the driver docs.  see the comment i added here: http://zelea.com/project/votorola/g/sql/Database.java
11:12 < mcallan> they recommend connection pooling, not creation of a new connection for every query!
11:14 < mcallan> conseo: we can optimize that later.  it will take a little work, because Database itself is not thread safe.  meantime it might not be super efficient, but at least it is correct
11:45 < conseo> the problem is that i need to query a lot of data if i track state in the db (maybe 20 queries per second (one for each active harvesting forum)). if they are synchronized with all db accesses (of voteserver as well) then this will be an issue. connection pooling is proposed in their article as well as suggested in the linked postgres documentation, because all the postgres driver does is synchronize accesses to the
11:45 < conseo>  Connection object itself.
11:46 < conseo> or am i wrong? we can skip it for now, but i think it will be a problem eventually
11:53 < mcallan> premature optimization is usually the bigger danger.  and then when it comes time to optimize, you never do it blindly.  you always use a profiler to identify the bottlenecks and measure the speed improvements ...
11:53 < conseo> ok
11:54 < mcallan> database sync only applies to a single vm - actually to a single classloader - so there is still a lot of parallel access going on ...
11:55 < mcallan> no, i wouldn't worry about it.  focus first on a robustness, ease of understanding, clear docs, that kind of thing ... we'll optimize later, at the last possible moment - that's almost always the best
12:00 < conseo> ok
--- Log closed Mon Jun 18 00:00:18 2012