Knut Anders Hatlen wrote: > > derbyfan195 <[EMAIL PROTECTED]> writes: > >> Knut, >> >> Thanks for your response. I'm more interested in not having to establish >> separate connections for each thread as I've noticed establishing >> connection >> in Derby takes a while, so if I can use the same connection among the >> different threads (with some synchronization), that would be the ideal >> case >> for me at the moment. >> >> What puzzles me is that you said when you close a ResultSet on a >> connection, >> all other ResultSets lose their position. My understanding is that from a >> Connection, you get a Statement, and from a Statement, you get a >> ResultSet. >> Having multiple ResultSet from the same Statement is troublesome, but I >> thought ResultSets from different Statements should never have conflict >> with >> each other, i.e., if I close a ResultSet on Statement A, it shouldn't >> affect >> another ResultSet that's opened on Statement B. Is this understanding not >> correct? > > Yes, I believe this is correct when auto-commit is turned off. When > auto-commit is turned on, closing one ResultSet may affect all > ResultSets in that Connection, even if they were created by different > Statements. > > -- > Knut Anders > >
Thanks much! I'm wondering what would be the best solution here with minimal code change. One option is to use a semaphore among the different threads so only one thread will be able to read that database table. Our app is not performance critical, so losing some performance is ok for us. But is there something even easier? e.g., configure the database table so only one reader can access it at any time? That won't even require code change. Any thoughts? - Hai -- View this message in context: http://www.nabble.com/Does-using-DerbyDB-require-synchronization--tp19379460p19394514.html Sent from the Apache Derby Users mailing list archive at Nabble.com.
