[tbnl-devel] ajax / tbnl

Tolstoy tolstoy at zentrope.com
Fri Dec 16 23:53:49 UTC 2005


On Fri, 2005-12-16 at 21:09 +0100, Edi Weitz wrote:
> On Fri, 16 Dec 2005 11:44:53 -0800, Tolstoy <tolstoy at zentrope.com> wrote:
> 
> > I'm working on an ajax kind of thing and when my html page loads, I
> > attempt to init the page's data structures by firing off many
> > XmlHttpRequests.
> >
> > When I fire off two of them, things work fine.  (One populates the
> > main data I want to display on the page, another populates a form
> > with some drop down list.)
> >
> > When I add a third asynchronous request, things break.  Alas, I'm
> > not exactly sure how to explain it.
> >
> > The way I'm seeing it at the moment is that the Oracle OCI shared
> > lib throws an exception ORA-21500 which takes down SBCL, I think, or
> > at least slime.

> 3. Oracle can definitely handle simultaneous requests but of course
>    you need a different database connection for each thread.  If you
>    don't have that this is most likely where your problems come from.

This was indeed the problem, as I suspected just after hitting the
"send" button.  If I add :if-exists :new to the (with-connection) macro,
things work as I expect.  If I add :pool t, however, transactions don't
seem to be committed even if I explicitly (set-autocommit t).  But this
isn't the place, I guess, to discuss that.

> ORA-21500 seems to imply some problem on the client side so I guess
> it's something like #2 or #3.  If it's not #3 (pilot error) it might
> as well be that there's a bug in CLSQL that nobody has encountered yet
> because not many people use CLSQL with Oracle and SBCL.

I think the prob was attempting to use the same connection
simultaneously.  The solution is either to acquire a lock, or create a
new connection for each transaction (which I imagine is a performance
issue).  I think the error came from the shared lib itself, rather than
SBCL or CLSQL.

> And of course this can also be a problem with TBNL.  I don't think
> TBNL is free of errors - it's just that this sounds more like
> something else.

Yeap.  I couldn't think of why TBNL would be at fault, but figured a lot
of people use the two tools together, so....

Anyway, thanks for the help! ;)

Keith

> Cheers,
> Edi.




More information about the Tbnl-devel mailing list