Rickard Öberg wrote:
> Hi!
>
> Nishi Nidamarty wrote:
> > 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.
>
> No, it is expected that the database vendor provides the DataSource
> implementation. The app server vendor may provide generic wrappers in
> the form of connection pooling datasources and such, but it is not a
> requirement.
I agree with you totally when you say DataSource implementation needs to be
provided by DB vendor.
To provide these wrapppers for Connection Pooling or to make use of these new
extensions the App Server should implement the "DataSource" class, the
interface being provided by the DB vendor. That is what the 6.3 section says.
This is not like a generic wrapper, but the DB vendor should provide the App
server with the DataSource interface which the App Server would implement to
support it's own Connection Pooling.
>
>
> >
> > >> 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)?
>
> Sure it can. Just look it up in the JNDI namespace. Why do you think the
> app server, or any of its components, cannot use the DataSource?
>
I'm not saying that the App Server cannot make use of the DataSource
registered in JNDI.
I'm interested if that would impact what an App Server can do in terms of
controlling transactions in a component based framewok like EJB using a
vendor provided DataSource.
I hope I am clear here.
>
> > So in that case I guess the app server only need to know the intial
> > setup like (port, DB etc).
>
> Yes. This is typically provided by showing some visual customizer for
> the DataSource to the system administrator. See JavaBeans API for
> reference.
>
> > 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.
>
> Not sure what your question is here. Can you explain more?
Will the DataSource class provided by the DB vendor, get the information from
the App Server handling connection pooling, distributed tranactions? I guess
these "hooks" in JDBC extensions address this. I'm wondering is this kind of
manadatory in component based EJB framework where transaction demarcation is
done at component level.If not how the App Server passes the "tx" details to
the RM (local tx) or a TM (global tx)
>
>
>
> > >> 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?
>
> Different components have different transaction needs. They need to tell
> this to the app server, so that it can "forward" these needs to the TM
> in an appropriate manner.
So you are saying that App Server is the one which informs the TM, so looks
like it then needs to support these so called "hooks" (JDBC 2.0 std.
extensions) by implemeting the "DataSource" class provided by the DB vendor.
Coming back again to my first question are these "hooks" kind of requirement
or is it optional? which is still not clear to me :)
I'm really trying to understand what kind of App Servers need to support
these new JDBC std. extensions. Is it a requirement? What is the rationale
for the DB vendors to allow the app servers to implement these "hooks"?
Sorry if I'm not clear with my idea.
>
>
> /Rickard
>
> --
> Rickard Öberg
>
> @home: +46 13 177937
> Email: [EMAIL PROTECTED]
> Homepage: http://www-und.ida.liu.se/~ricob684
===========================================================================
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".
