Re: Re: [JDBC] New backend functions? [was Re: JDBC ch

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23-Aug-2001 Rene Pijlman wrote:
> What should the semantics be exactly?
>
> How about the multiple INSERT's i've been reading about on
> hackers? ... Only the OID of the last row inserted by the
> statement?
>
> How about an UPDATE statement that updates multiple rows?

Well, here's my thoughts on this...

The functionality would be that the very last inserted or updated OID would be
stored in this static variable that is associated with the connection/session.
So, in multiple inserts or updates, it is the last oid affect where this
variable would be updated.

> How about triggers that insert/update extra rows? ... Only the
> OID of the row directly inserted by the client statement?

It would be the last updated request caused by any insert or update, regardless
of if its a trigger, preparedStatement, etc.

> How about Large Objects? Should inserting or updating a large
> object affect getLastInsertedOID()?

Yes.

> I assume this OID would be associated with a client connection.
> Is this going to work with client side connection pooling?

It must... that's the reason for this. Specifically, the JDBC driver has a
method in it that is called getInsertedOID() which provides the last
sucessfully inserted row's OID. This is specific to the driver, and JDBC
pooling techniques do not allow access to this method. (It's not part of the
JDBC spec) So, to make this data accessable to the users in a pooling
condition, the call "select getLastOID()" needs to return the OID that is
specific to the session.

In Java, pooling techniques generally are aquired, then released, as dependant
on the client or timeout procedures, and not randomly used for individual
queries. (Mostly because of the need for the same driver during a transaction
that takes multiple queries.)

> How about transaction semantics? INSERT row 1, Commit, INSERT
> row 2, Rollback... what should getLastInsertedOID() return? Can
> it, with a static variable?

Good question. I'd start with rollback not affecting this value. Reason being
that this function would be mostly used in a transaction anyways. I would not
object to making this method only available during a transaction block if that
helps.

Virtually,
Ned Wolpert <ned(dot)wolpert(at)knowledgenet(dot)com>

D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7hWEwiysnOdCML0URAk3xAJ92nYoy22mP4Yk8xk53vojlF42w5gCfbnZf
uexoQ9yqexctXvQM0yx+g2Y=
=yK6n
-----END PGP SIGNATURE-----