Just to reply to my own email, to get the tcp server to work for just a
single database it is necessary to override the TcpServer class and
override checkKeyAndGetDatabaseName() - see below. I actually quite like
this style of doing it, although it's doesn't look really to be designed as
a public API.
I think for me and many others the primary use case for production software
is where we want to fully control the mapping of url to database and hide
the file system. From this point of view the default tpc server and
auto_server are somewhat counterintuitive in what they achieve.
The default 'like a web server' tcp server for me and probably many others
is very unsatisfactory from a security point of view since it seems to
expose all h2 databases on a machine - many of which may not have an SA
password set. Also it's a bit untidy exposing the filesystem layout to
remote services. I would only use it in a development context.
Again for users like me the AUTO_SERVER is a bit of a red herring, since I
wouldn't generally architect things such that there could multiple
processes opening a database on the same file system, or at least not for
server style software. I think the immediate thought and a certain amount
of confusion arises from this, is that the autoserver is just embedded mode
for the primary process + tcp access to that database, but really it's a
performance complication in the event that multiple processes want to
access a database, possibly intermittently and it just allows concurrent
access when one process has the filesystem lock. It could be quite good
mechanism for say interprocess communication and data management on a
single machine.
So whilst nothing in the docs says otherwise, I did find it all a bit
confusing because I assumed my use case was very typical and would be
handled directly by one of the two mechanisms. Having looked at past
questions on this mailing list and stack overflow I'm perhaps not the only
person who thought like this.
Also I now don't believe there to be any issue making multiple connections
in the same JVM. Presumably h2 keeps an internal map of open database
locations.
- mike
final String key ...
final File db ...
String port ...
TcpServer service = new TcpServer(){
@Override public String checkKeyAndGetDatabaseName(String
arg) {
if(key.equals(arg)){
return
FileUtil.canonicalFile(database).getAbsolutePath();
}else{
throw
DbException.get(ErrorCode.WRONG_USER_OR_PASSWORD);
}
}
};
Server server = new Server(service, new String[]{"-tcpPort",
port, "-tcpDaemon", "-tcpAllowOthers"});
service.setShutdownHandler(server);
server.start();
return server;
On Tue, Jul 26, 2016 at 6:46 PM, Mike Goodwin <[email protected]> wrote:
> Hi,
>
> I was wondering how best to do a remote tcp connection to a single
> (already existing) database.
>
> The auto server mode would be ideal, but apparently you cannot access it
> using a server+port url. Is there a technical reason for this limitation?
> For me the documentation is a little confusing when it talks about
> accessing from other computers. I think in some worlds such as mine shared
> drives are a lot less of a factor.
>
> The alternative seems to be starting a tcp server. Can this be mixed with
> embedded connections? Not being able to use an embedded connection is
> undesirable (but not disastrous). The biggest issue though is it seems to
> give access to all other databases on that machine. I don't want to expose
> the database path details to the client. I would ideally just like to open
> the server for a given database on a given port. Is this in anyway possible?
>
> regards,
>
> Mike
>
--
You received this message because you are subscribed to the Google Groups "H2
Database" 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 https://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.
