db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: [DRDA] Question about DRDAStatement.initialize() method
Date Thu, 23 Feb 2006 23:50:36 GMT
Kathey Marsden <kmarsdenderby@sbcglobal.net> writes:

> Deepa Remesh wrote:

>>I have couple of questions:
>>1. I find it confusing to have a initialize and reuse method with
>>similar comments. Can initialize be removed since we can call
>>setTypDefValues directly at places where it is currently called?
> I must say I find every use of initialize() absolutely perplexing except
> for the one in  parseEXCSQLIMM,
> but regardless they all seem to be resetting the defaultDRDAStatement
> for reuse, so I think initialize can go away and you can  use your new
> reuse() method. I think you can have a reuse, with or without a database
> parameter.

I think you are right, Kathey, but I'm absolutely not sure. I too find
the calls to initialize() odd (except parseEXCSQLIMM()).

Would it make sense to add a call to setTypDefValues() in reuse()? At
least when database != null? In that case you could replace all calls
to initialize() with reuse().

>>2. initialize() is called at called at 5 places in the server code.
>>Two of these places (DRDAConnThread methods parseEXCSQLIMM and
>>parseEXCSQLSETobjects) have the following comment:
>>// initialize statement for reuse
>>I am not sure about the actual intention of calling initialize() at
>>these places - whether it is to just reset the typedef values or does
>>it expect all fields to be reset for reuse. Can someone familiar with
>>code look at these places to see it is enough to use initialize() at
>>these places? If this does not look right, I can open another issue
>>for this.

If the intention was to reset the typedef values, I guess
setTypDefValues() would have been used instead of initialize(). The
comments indicate all fields should be reset.

>>3. Is my comment for the new reuse method() okay? specifically, the
>>comment about fields which should not be reset?
>>"This method should reset all members of this class except the
>>following which will be set at initial creation or set explicitly in
>>the code: database, pkgnamcsn, pkgcnstkn, pkgid, pkgsn"
> If these can be reset too that would be good and then get set whereever
> the get set just for completeness.

If you reset these variables, you'll need to call
DRDAStatement.setPkgnamcsn() and DRDAStatement.setDatabase() later. In
DRDAConnThread, setPkgnamcsn() and setDatabase() are not called after
DRDAStatement.initialize(), so you'll have to add those calls there.

By the way, setDatabase() calls setTypDefValues(), so you could try to
replace initialize() with

  reuse(); // including database, pkgnamcsn etc.

> I wonder if reset() is beetter than reuse, but I am the worlds worst
> namer.

+1 to reset()

> Will there be a reuse() in DRDAResultSet as well?

+1 to that too.

> Will close no longer reset these values and the reuse only called when
> the statement is reused?
> Even with the rename, I worry a little about the maintainability of
> this.  Part of that is just that DRDAStatement is way to busy and I
> think the ParameterMetadata should be broken out some day..

Knut Anders

View raw message