Re: AW: jca adapter for (MySQL)DB

Some use case for wrapping JDBC drivers as connectors.

Typically an application server has implementation specific way to wrap a JDBC 
driver and use it with its transaction manager, pooling infrastructure etc. 
So, it may be possible that some application servers would support only 
ceratin kinds of JDBC drivers. 

There are four ways of getting JDBC connection (for different purposes)...
1. DriverManager, 2. DataSOurce 3. ConnectionPoolDataSource and 4. 
XADataSource.

If a driver support only certain kinds of 1, 2, 3 and appserver supports again 
certain kinds of 1,2,3 then deployment/integration of JDBC drivers to 
application servers would be incomplete. I want to treat XA as different.

In case you have a JDBC resource adapter (or use JDBC Connector to wrap the 
driver) then we know that the deployment/integration of JDBC driver to any 
application server (that is j2ee1.3 compliant) is complete.

thanks,
Binod


On Saturday 09 August 2003 01:30 am, Johan Eltes wrote:
> No, it does not replace XA. But it gets you quite some steps closer to XA
> than you could without using a connector. My response is only referring to
> the JDBC api, not to anything for which you could write a connector. If I
> would try to generalize the properties that makes this possible for JDBC,
> but not necessarily for any EIS, it would go something like:
>
> An api that has the concept of a local transaction, where it would make
> sense to apply the programming model for J2EE, when wrapping it in a
> connector:
> - dis-allow a call to begin/commit/rollback operations( or their
> counterparties) of the connection interface while in a JTA transaction.
> - Program the resource adapter to call these methods as the implementation
> of the start / end transaction callback methods.
>
> What makes an EIS dis-qualified? Well, if each operation is executed as an
> atomic transaction, the EIS would not lend itself to the J2EE programming
> model. If the EIS provides a concept of local transactions, whit an
> implicit or explicit begin-operation and explicit commit and rollback
> operation, it would likely qualify.
>
> /Johan
>
> Den 03-08-08 21.14, skrev "Ramakrishna Srinivasa"
>
> <[email protected]>:
> > I wonder if it possible to do like this. When the underlying Database/EIS
> > System doesnt support XA , how is possible to achieve it with a JCA
> > Adapter. For example SAP by itself doesnt support 2PC. Do you mean to say
> > that a JCA Adapter for SAP can support 2PC ? In that case who will store
> > the data which is uncommitted , should the Adapter take care of this?
> >
> > I am sorry, if I misinterpreted your answer.
> >
> > //Ramki.
> >
> > -----Original Message-----
> > From: A public list for J2EE Connector architecture interest. on behalf
> > of Johan Eltes
> > Sent: Fri 8/8/2003 10:05 PM
> > To: [email protected]
> > Cc:
> > Subject: Re: AW: jca adapter for (MySQL)DB
> >
> >
> >
> > To some applications, it could be of value to wrap a none-XA JDBC driver
> > with an XA connector to mimic XA by deferring the commit/rollback call to
> > the wrapped JDBC driver until the end of the jta transaction. It is far
> > from XA but may be sufficient for the application at hand. I guess MySQL
> > doesn't support XA?
> >
> > /Johan
> >
> > Den 03-08-08 20.38, skrev "Ram Jeyaraman" <[email protected]>:
> >> It is important to separate out SPIs and APIs to understand the
> >> relationship between JDBC and Connectors.
> >>
> >> JDBC is primarily an API, and Connectors is primarily an SPI. CCI is
> >> just only
> >> type of an API a Connector can expose, JMS is another, and so on.
> >>
> >> At the system level, the JDBC driver contracts and the Connector
> >> contracts are
> >> very similar. That is the reason why some vendors choose to implement
> >> JDBC driver as a Connector and expose JDBC as an API to the application.
> >>
> >> Really from the application perspective, it does not matter, whether the
> >> JDBC API is exposed via a JDBC driver or a Connector. thanks.
> >>
> >> ========================================================================
> >>=== To unsubscribe, send email to [email protected] and include in
> >> the body of the message "signoff CONNECTOR-INTEREST".  For general help,
> >> send email to [email protected] and include in the body of the
> >> message "help".
> >
> > =========================================================================
> >== To unsubscribe, send email to [email protected] and include in the
> > body of the message "signoff CONNECTOR-INTEREST".  For general help, send
> > email to [email protected] and include in the body of the message
> > "help".
>
> ===========================================================================
> To unsubscribe, send email to [email protected] and include in the body
> of the message "signoff CONNECTOR-INTEREST".  For general help, send email
> to [email protected] and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff CONNECTOR-INTEREST".  For general help, send email to
[email protected] and include in the body of the message "help".