"Jim Starkey" <jas@...> wrote in message
news:42E50059.2060108@......

>
> The solution to the problem is already in place due to early and
> effective lobbying by Paul Ruizendaal: the InternalConnection class
> implementation of the Connection interface. This mechanism was

invented

> for the explicit purpose of exporting database semantics and

context to

> external procedures. An InternalConnection object is obtained by

the

> internal engine method Attachment::getUserConnection

(Transaction*). The

> connection object provides a clean, architecturally supportable
> interface to internal engine functions using the JDBC paradigm.

What about other extension types besides triggers and procedures?
Extarnal scalar functions? Aggregate functions? These should have
separate interfaces that don't provide database connection. In the
long run, the interface to external-defined functions should have
become no different to the internal ones.

Also, it would be necessary for external procedures that have side
effects to participate in transactions. Thus, the engine may
establish 2PC transaction between itself and any involved external
providers. There are magnitudes of gains that can be achieved by
that - logging, replication, data distribution, etc.

Regards,
Aleksey Karyakin