Hi,

> >>>>In that light is makes
> >>>>sense to tell RDBMS that some statements have to be in the buffer
> >>>>permanently, e.g. those executed 10x per second. Well, this is
> >>>>
> >>>>
> >impossible
> >
> >
> >>>>probably as the buffer is not shared between connections.
> >>>Something that is likely to appear in a future version is a compiled
> >>>statement cache which will be cross connection.
> >>>
> >>>
> >>>
> >>Ah ha!!!
> >>
> >>That would be excellent!
> >>
> >>Especially as, over a slow connection, the slowest thing is the
> >>prepares. So if you only have to do it once, for all the users, it could
> >>make things much faster.
> >>Would this cache be persistent (that is, you would be able to prepare
> >>statements once and for all), or would they get unprepared as soon as
> >>the transaction that prepared them gets closed?
> >>
> >>
> >
> >Transactions don't get closed, they get committed or rolled back.
> >
> Getting committed or rolled back is what I call getting closed. Because
> after that point, it's no longer open (active). Why get hung up on words?

To avoid confusion. What does "closed" mean? Commit or rollback?
How can you "close" something that hasn't been "open"?

> >Prepared statements have nothing to do with transactions, only with
> >connections.
> >
> Ok. So does that mean that if I commit my transaction, the statements I
> prepared will still be prepared?

From what I have understood, yes. I'm not sure if the regular
componentsets actually do this.

With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server.
Upscene Productions
http://www.upscene.com