Oh - wait. You were *suggesting we add that*. The light goes on.
Okay, well, better to just turn blocking on. The point of
blocking is to block, and the underlying pool already handles that. The
point of not blocking is to allow the "client" to gracefully abort if the
resource is not available. So you could display a "resource
unavailable; please try again later" message or whatever. This is
admittedly not what you usually want to do in an EJB, so we can turn
blocking on by default. But if for some reason you *do* want to do it, we
should not defeat it in the data source, we should let it happen.
So I'll change blocking to default to on, and then if someone
wants it to not block, they can change that easily.
Aaron
On Sun, 8 Oct 2000, Aaron Mulder wrote:
> I don't understand. When I look at both getConnection methods
> in XAPoolDataSource, in the version on my disk and the latest version in
> CVS Web (1.4), *there is no loop*!!! It just does
>
> return ((XAConnection)pool.getObject()).getConnection();
>
> Furthermore, the underlying pool itself *does* use wait and
> notify. What on Earth are you talking about?
>
> Aaron
>
>
> On Sat, 7 Oct 2000, Daniel Schulze wrote:
> > Aaron,
> >
> > meanwhile I had a look at the minerva code
> > (XAPoolDataSource.getConnection (*) lines 167-183).
> >
> > The problem is exactly what I assumed it is...
> > A fragment like:
> >
> > Object o = null;
> > while ((o = pool.getObject()) == null);
> > return ((XAConnection)o).getConnection ();
> >
> > would fix the problem in both getConnection methods.
> > But instead of this ugly cpu killing loop, I think it would be better
> > to set the pool used by this DataSource object always to blocking. (So
> > that the cpu killer is only on one place ;-)
> >
> > Tell me what you think of it and if you will fix it or if I should do
> > it!
> >
> > /bye Daniel
> >
>
>
