[Mulgara-dev] ItqlIntepreterBean/TqlInterpreter/JTA

Life is hard, and then you die ronald at innovation.ch
Thu Feb 7 04:24:39 UTC 2008


On Wed, Feb 06, 2008 at 07:58:44PM -0600, Paul Gearon wrote:
> 
> On Feb 5, 2008, at 9:43 PM, Life is hard, and then you die wrote:
> 
> > I've been looking at the latest mulgara in the jta branch (mgr-73
> > branch), and hit upon some questions regarding the current
> > ItqlInterpreterBean and TqlInterpreter.
> >
> > First of all, I see that ItqlInterpreterBean is deprecated; but it has
> > been changed in incompatible ways (there is a compile-time
> > incompatibility because of the getLastError() being renamed to
> > getLastException(), and there are run-time incompatibilities too, i.e.
> > the same app code that works with 1.1.1 doesn't work with trunk). Is
> > ItqlInterpreterBean supposed to be backwards compatible?
> 
> Yes.  Evidently I was careless.  Sorry about that.  The unit tests  
> that use ItqlInterpreterBean all passed, and I didn't go any further  
> than that.
> 
> I'll change that method name back (I can't recall why I changed it - I  
> must have been drunk with power).  Once that's done I'd appreciate  
> finding out what old code doesn't work anymore (if it's just message  
> and error strings, then I'm not too worried).

The run-time problems are related to trying to use a local
DatabaseSession (server-uri = local:///...). I'll do a little more
debugging and try to fix it.

> > Second, am I right correct in understanding that TqlAutoIntepreter is
> > sort of interim replacement for ItqlInterpreterBean, but that the real
> > move is for apps to start using Connection and TqlInterpreter instead?
> 
> Yes.  Don't you prefer this?  Everyone else I've spoken to thinks it's  
> a better idea.  :-)

Sorry, I didn't mean to imply in any way that I didn't like the new
stuff - I was just trying to understand what the plan was. In short,
yes, having an explicit connection over which you send stuff is much
better.

> I mean, ItqlInterpreterBean actually established connections as a part  
> of the query parsing process.  So getting a session was mixed in the  
> SableCC code.  Call me old fashioned, but I think that idea just plain  
> *%#$ed.

Agreed. Especially when want to have different ways of talking to the
server. For that reason we've written our own mulgara-client library
that provides a simple, unified way to talk to mulgara over rmi, soap,
to an embedded instance, or to a memory-only embedded instance.

> > Part of my questions are motivated by the need to get at the Session
> > in order to be able to get the XAResourceC - TqlAutoIntepreter won't
> > let me do that, and the ItqlInterpreterBean returns null for the
> > session unless the session was explicitly passed in, so it seems the
> > TqlInterpreter+Connection is the only way to go.
> 
> I have no problems with you adding an interface to TqlAutoInterpreter  
> if you'd prefer to use this class.  However, since it can change to a  
> new connection with every query, then it could get very hairy very  
> quickly.  It already has to be careful to track every connection that  
> it's trying to perform a transaction on.
[snip]

Agreed. Again, I have no problem with using Connection and
TqlInterpreter - it's just that suddenly there are these new classes
and ItqlInterpreterBean has been changed underneath to use them, and I
was trying to figure what the intent of things was (a mail to one of
the lists explaining the changes might've helped ;-) )


  Cheers,

  Ronald




More information about the Mulgara-dev mailing list