[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