RE: JDBC 2.0 Api compliancy and integration

From: Peter Mount <petermount(at)maidstone(dot)gov(dot)uk>
To: "'jwm05c(at)mizzou(dot)edu'" <jwm05c(at)mizzou(dot)edu>, ML-Postgres-Interfaces <Pgsql-Interfaces(at)postgresql(dot)org>
Subject: RE: JDBC 2.0 Api compliancy and integration
Date: 2000-10-27 07:46:26
Message-ID: 1B3D5E532D18D311861A00600865478CF1B486@exchange1.nt.maidstone.gov.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

Comments prefixed by PM:

--
Peter Mount
Enterprise Support Officer, Maidstone Borough Council
Email: petermount(at)maidstone(dot)gov(dot)uk
WWW: http://www.maidstone.gov.uk
All views expressed within this email are not the views of Maidstone Borough
Council

-----Original Message-----
From: Jason McIntosh [mailto:jwm05c(at)mizzou(dot)edu]
Sent: Thursday, October 26, 2000 5:38 PM
To: ML-Postgres-Interfaces
Subject: [INTERFACES] JDBC 2.0 Api compliancy and integration

Does anyone know the level of compliancy of Postgres with regards to
record locking. Specifically, which transaction levels it supports (if
any), and how well it supports them. I've been using the Oracle JDBC
drivers, and was saddened to find they only support
TRANSACTION_SERIALIZABLE and TRANSACTION_READ_COMMITTED, but the
READ_COMMITTED did very little in the way of record locking.

PM: We have some but not much. What was done was for the standard
extensions, so personally I'm not entirely sure how much is actually
implemented.

I'm trying to set it up so a java.sql.ResultSet can read all the records,
even those that are "locked", but when someone actually updates that
record, any attempts at modification or updates by that open ResultSet
fail. this is in specific reference to executeUpdate() and sending a SQL
Update string.

PM: I don't think we support this. Once a ResultSet has been read from the
backend, it has no communication with it, so there is no way for the
ResultSet to know of any changes to it's underlying records. Without
implementing a trigger to send a notify message, I'm not sure how we could
implement this transparently.

Thanks!
Jason McIntosh
Programmer/Analyst Specialist
University of Missouri, Columbia

/------------------------------------|-------------------------\
| Jason McIntosh | CELL: 573-424-7612 |
| Webmaster, thinker, etc. | WORK: 573-884-3865 |
| http://web.missouri.edu/~c717990/ | |
| "Why do we crucify ourselves, every day, I crucify myself" |
| - Tori Amos |
\------------------------------------|-------------------------/

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>

mQENAzmm0doBbQEIALDxptSSC6H10egnCYgnGuMT9HwUJCJYHoj0pue2+OCsOuX8
ZE38nXS7RDOikfvDI3w3X85AisFW2d9omzohSZhkFIfo0SJpFoq0uIZWnQMHYz5T
9A/dzTnvdAHZTuF1qtW5hDBzBexmktQYfWCG32vA4kSeSfGJZK8tmHtvxF0WgEWE
sV2pmidixbSRFz7pdZHzRc5MkJ7Vrg8oEy9B53iAka3Aliddd9s6TVeVWDEG5rZ0
XJtiRTb6AXETQsZTqv5dKJRos6enLZyBMEdC2pCdj0JIIlmGU/yoCjsuJL3x0TrE
iMXF1nyfnWNUzzxhvOpyxmi14e0NaNJwBg4F700ABRG0LEphc29uIE1jSW50b3No
IDxjNzE3OTkwQHNob3dtZS5taXNzb3VyaS5lZHU+iQEVAwUQOabR2mjScAYOBe9N
AQHB7Af/WpQWThUFbHsL0mT9RxdcZsaBFKXedp/FTm1F9nFgDYMhH/wYMihC7016
xOv6IY4WCyvkJSGwDei06pk9W/b6dLukijShf5lmOUuA8NWYjGUtYszFzzPLQ5zn
AiV8jwb3K+J/J1wcmTcu/Th0T8qu5cNoAvnMbnx91k7Wf9Kjfg20YJteCFgLcYhq
tGyiSbK35CrbiIpb13dDeDrQadz/FAqE3WWK6GYSr7htmDp5ER0fPqLe0RzAQofO
kx/PKNL+RZ2Ya65svYj+QcnT5oS3iKa5GdvleWMt5zST8clJDCV8V4T4sOrMTkxq
wFUfFy0pst3UX4QypJuPP7CoKx9B+g==
=l64r
-----END PGP PUBLIC KEY BLOCK-----

Browse pgsql-interfaces by date

  From Date Subject
Next Message Peter Mount 2000-10-27 07:56:55 RE: Re: new maintainer for the ODBC driver?
Previous Message Constantin Teodorescu 2000-10-27 05:20:19 Re: Question about pgaccess