Hi again,
to clarify what I mean, I roughly implemented it in attached patch... or at least I think I did, it is *COMPLETELY UNTESTED* and just serves the purpose of stating more precisely what I described.
Kind regards, Ralf
On Monday 17 October 2011 15:26:15 Ralf Jung wrote:
Hi,
yes, that's a good point. We'd probably have to check somewhere (e.g. in the HTTPSession.local() method) if a server exists in the same JVM. If you have a spontaneous idea how to perform this check.. Feel free to tell us ;)
Is using LocalSession safe if there can be concurrent queries through the native interface, i.e. concurrent ClientSession (and of course other LocalSession) accesses?
The decision (Local vs. Client) is complicated by the fact that the logic when a native BaseX server is launched, is quite complicated: It is started if the -l flag is NOT present AND the HOST property is set to something different from "localhost". I would have expected to control that directly via some flags, for example:
- "basexhttp" starts the API plus a local native BaseX server
- "basexhttp -l" starts just the API (local mode)
- "basexhttp -r" starts the API and connects to a remote BaseX server to
execute the queries etc. on (remote mode) In the first two modes, LocalSession could be used (if it can be used concurrently, see above). It must not be possible to pass both the -l and -r flag. This would keep the default behaviour, and would remove the "magic" of the server launch happening or not. IMHO that's a quite significant difference, because it decides which data is going to be used. But maybe I just have a strange intuition ;-)
Kind regards, Ralf _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk