[Mulgara-dev] Connection/Command questions
Paul Gearon
gearon at ieee.org
Thu Feb 7 02:38:16 UTC 2008
On Feb 6, 2008, at 2:46 AM, Life is hard, and then you die wrote:
> Looking at the Connection and Command classes things seems a bit odd,
> and I'm curious why it's done this way.
Not all commands need a connection to be run, and they therefore
ignore this parameter. Then there are command like ApplyRules which
need 2 connections (though the default is to use the same connection
for both parameters).
The other reason is that I prefer to have each class do the work
specific to it, rather than lots of methods all in a single class. So
instead of Connection having an execute(...) method for every type of
Command, instead, every Command has an execute method specific to
itself.
You're right in that it seems conceptually backwards for simple
operations like querying and modifying data. But then I changed my
mind when I thought about those commands that didn't need a connection
at all.
> What I normally would've
> expected is that commands are passed to a connection, but instead it's
> the opposite. This means that it doesn't seem possible to batch
> commands. Given the overhead, whether rmi or soap doesn't matter, I'm
> not sure that's a great idea. For example, I often see times of 10ms
> to execute a query, but 50ms - 60ms for the transport overhead. We
> regularly batch queries, partly for this reason.
It's always possible I was thinking backwards at the time due to
spending too much time using the visitor pattern. The previous
ItqlInterpreter code works out what it's doing, and then tells this to
the current session. I guess I followed this paradigm in that the
command (once it's generated) tells the session what it needs to do.
It's possible to invert the calling pattern, but I don't think the
result would be all that clean.
Another alternative would be to create a CommandList, which holds a
List of commands, and sends them over RMI to be executed at the server
end. This would need a new method on Session, but I think you were
going to need that anyway (at least while parsing at the client end).
There will be some overhead sending all this over the wire, but it
should be pretty small. However, this won't be as good as simply
constructing commands at the server end. Let me get to that in a
moment...
> The other thing is the current setup seems to require itql parsing be
> done on the client side, since Connection provides a Session. This
> would seem to increate the transport overhead and in general the work
> needed for a new transport, as instead of sending a simple string you
> have to provide serializations for all the constraints, and on top you
> have to write new serializations for each new transport.
>
> Am I overlooking or misunderstanding something again?
There are two reasons for this appearance.
The first reason is that TQL parsing has always been done on the
client side. I wasn't changing the transport protocols, just the
method of using them. So the current setup where queries are parsed
by the client has remained unchanged.
The second reason is because I fully intend to parse at the server
end, but since the services for this are not up yet the interfaces
were not done. The plan here was for a LocalConnection class for
commands to be executed on.
A simple example is to accept a simple socket connection (say, HTTP),
parse a query received on this connection into a command, and then
execute the command on a LocalConnection. The results then go back
out the socket. Once we have this done, then multiple commands should
become easy.
Paul
More information about the Mulgara-dev
mailing list