Common strategies for implementing servers using non-thread-safe objects: use one object and ensure only one thread uses it at a time (the actor model), allocate a new object per request, or (if creating an object is expensive) pool objects and re-use them for later requests.
> On Feb 15, 2019, at 12:47 PM, Vladimir Sitnikov <[email protected]> > wrote: > > Julian> Indeed, JDBC itself is not thread-safe > > Just in case: CalciteRemoteDriverTest seems to be pretty sane test (it > does not use the same java.sql.Connection across multiple threads), > yet it fails with race-condition-like reasons. > > I won't really want to dig into JDBC thread-safety, however that is a > slippery slope. I used to think that JDBC is not thread-safe, however > now I don't think so (after being pgjdbc maintainer for a several > years). > For instance, there's Connection#getWarnings, and clients expect that > to work from a separate thread while statement is still running (and > producing warnings). > There's #close which apparently should be thread-safe (e.g. to play > well with automatic flnalize-like cleanup). > Threre's Connection#abort, and so on. > > Julian> So, the solution is not necessarily to add locks and/or > synchronized all over MetaImpl. > > Apparently the solution is to replace "connection" and "connProps" > fields of MetaImpl with Map<ConnectionId, ...> kind of field. > It is really hard to imagine a HTTP service that produces correct > results only in case it is accessed from within a single connection > only. > > For instance, connectionSync is a separate wire command, so currently > it just overwrites MetaImpl field, and it is pretty close to plug&pray > kind of technology. > I wonder how it managed to survive for such a long go. > > > I'm not sure how much sense MetaImpl(AvaticaConnection connection) > constructor parameter makes. > I think connection creation should happen in > org.apache.calcite.avatica.MetaImpl#openConnection > > Of course, MetaImpl might want to have a connection instance for calls > like catalogs(), then it could just call openConnection on its own and > that's it. > > Am I missing something? > > Vladimir
