On Aug 3, 2009, at 11:31 PM, Roman Rokytskyy wrote:

> > Doing it that way, I'll be creating a new FBMC, rather than
> getting one from the pool. I guess I'll need to clean it up, too. So
> I register a ConnectionEventListener with it that calls
> FBMC.cleanup() and FBMC.destroy() if the connection is closed or an
> error occurred. Does that sound right?
>
> I do not remember if you need to register listener in a managed
> environment. In a non-managed you need to call destroy(), but I would
> try without the listener first.
>

The listener is added by the managed environment. However the main
purpose of the listener is to make sure the managed connection doesn't
get back in the pool if something goes wrong. Since you didn't get
the MC from the pool, that's irrelevant, and you don't need to add a
listener unless you want some kind of independent notification that
the recovery couldn't access the db. What you should make sure of is
that the MC is destroyed after recovery is over: there's no way to
tell the pool to add it in alongside the MC's the pool created.

>
> > When I create a new FBMC, I'm planning on getting the necessary
> CRI info from the FBMCF (i.e. getDatabaseParameterBuffer()). I'll
> also build the Subject with the username and password from the FBMCF.
>
> There is method getDefaultConnectionRequestInfo() and you can use null
> as subject (that means that it will use preconfigured user and
> password).
>

I agree

thanks
david jencks

>
> Roman
>
>