[EMAIL PROTECTED] wrote:
> Trying to inderstand the new JDBC 2.0 standard extensions.
>
> 1. the Connection Poolng section (6) pg 17 para 2 says
> "a middle tier server who wishes to implement connection pooling
should provide a data source class"
>
> If the middle tier does not wish to support "DataSource" class who
implements the "DataSource" and who registers it in the JNDI?
>> Then the middle tier does not wish to support JDBC 2.0 Connection
Pooling...
> 2. The document only says that app server need to implement
"DataSource" and JDBC vendor "DataSource_intf", and does not explain as
to why the app > server need to implement this?
> Can't the app server make use of DataSources registered in the JNDI by
the Database?
>> Where did you read this? I don't see any reason as to why the server
>> should implement DataSource.
In section 6.3 and whenever they speak about "DataSource" in later
sections, I was assuming that it expected by the app server vendor to
provide "DataSource" object to make use of this new JDBC (2.0)
extensions.
>> The database does not bind the DataSource
>> into JNDI. The system administrator typically names the DataSource
>> implementation in his server configuration tool and since
DataSource's
>> must follow the JavaBean API guidelines when it comes to
configuration
>> (see JDBC2.0, section 5.3) it can be easily deployed in a server
without
>> the DataSource being implemented by the server vendor.
Binding the "DataSource" is certainly not the issue. Can the app server
make use of a "DataSource" provided by the DB (after binding it in the
JNDI)?
So in that case I guess the app server only need to know the intial
setup like (port, DB etc).
I guess the document is more for an app server who wishes to support
connection pooling, distributed transactions support (it's own JTS
implementation). Or is this is mandatory in a 3-tier especially EJB
framework. The app server should be able to make use of XA and
Connection Pooling provided by the DB vendors.
> 3. Can't we bypass the app server once we connect to the database via
JDBC, especially to handle distributed transactions?
>>How do you intend to do this?
> 4. If we have an DataSource (with XA support) registered in JNDI and a
TM which can manage distributed transactions.
> What exactly does the EJB framework need to handle to support
application level transaction demaracation?
> WHY?
>> The tx demarcation mgmt tells the TM (roughly) when to start new
tx's,
>> and when to commit or rollback them. How should the TM otherwise get
>> these calls do you suggest?
can't this be done at RM level via the connection in JDBC? We can pass
the the tx demarcation details to RM via connection (just a guess).
Why do we need to have an App Server in between?
TIA,
Nishi.
-
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
