Menu
▾
▴
springframework-developer
|
From: Thierry T. <te...@ya...> - 2005-04-11 11:50:56
|
Hi Juerguen, Great news ;-) I will checkout the JCA support from cvs as soon as possible... I see too that the JCA sample is in cvs but, I think that it doesn't use classes of the main sources. I will refactor it to use it. To finish, do you want that I update the documentation of the JCA support with your improvements? Cheers, Thierry > Everybody, > > I've finally moved over the JCA support from the > sandbox to the main > sources, in a reworked and extended version. The > structure of the "jca.cci" > package is analogous to the "jdbc" package. Aside > from the Common Client > Interface data access package, there's also > "jca.support" package for local > setup of a JCA connection factory (CCI or other). > > I've used Thierry Templier's JCA support prototype > as starting point - > thanks very much again, Thierry! In comparison to > this original version, > CciTemplate is stripped down to some extent. All > operations just use > InteractionSpec now; ConnectionSpec handling has > been completely removed > from CciTemplate, in favor of a special > ConnectionFactory (see below). The > execute methods follow typical use cases now, with > as much implicit handling > as possible. > > For example, there are no explicit boolean flags > passed to the execute > methods anymore. Instead, CciTemplate tries to > figure out the appropriate > behavior: if an output Record has been passed in or > if an > OutputRecordCreator has been specified, the > execute(InteractionSpec, Record, > Record) version will be used; else, > execute(InteractionSpec, Record). > Likewise for using the same Record as input/output: > simply specify pass in > the same Record as input and output argument; no > need to specify an explicit > flag for this anymore. > > I've also renamed MappingRecordQuery into > MappingRecordOperation (as there > is no true query concept in JCA; it's rather all > about generic operations > with a Record result), and factored out a separate > SimpleRecordOperation > class. The former is concerned with mapping input > and output objects to/from > CCI Records, while the latter simply passes in input > and output Records. > > Furthermore, there's a couple of ConnectionFactory > adapters, similar to our > JDBC and JMS support: for example, > SingleConnectionFactory. There's also a > special ConnectionSpecConnectionFactoryAdapter that > works analogous to our > UserCredentialsDataSourceAdapter for JDBC: > getConnection() calls will > automatically be routed to > getConnection(ConnectionSpec), with the > ConnectionSpec taken from the static configuration > of the adapter or from > the adapter's corresponding ThreadLocal. > > Feel free to give this stuff a try, either using a > CVS snapshot or the > upcoming 1.2 RC2! > > Juergen > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the hype. > Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > Take a look at my blog: http://templth.blogspot.com/ __________________________________________________________________ Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ |
|
From: Juergen H. <ju...@in...> - 2005-04-13 14:43:30
|
I'm not sure whether it is feasible for the Spring core to provide support for the JCA connection and transaction management contracts. This is beyond what Spring does in related areas: for example, we don't provide support for XA-enlistment of JDBC Connections from a local DataSource. This is where XAPool comes in: it includes an XA-aware pool facade that auto-enlists JDBC Connections with a given JTA TransactionManager and handles Connection state accordingly. Of course, XAPool is not a particularly exciting piece of software ;-) I would argue that there is a quite strong need for a better standalone XA-capable JDBC DataSource. While we're at it, JOTM isn't exactly perfect either; but compared to XAPool, it's still quite decent. For true 2-Phase-Commit, the resource needs to support the XAResource interface; in the case of JCA, via ManagedConnection.getXAResource(). So what's needed for JCA here is a generic XA-aware connection pool that provides auto-enlistment of connections, accessing the XAResource interface of the connector. I'm afraid that such XA-handling code is non-trivial to write. Essentially, we'd need to implement a javax.resource.spi.ConnectionManager that handles all of this for an arbitrary ManagedConnectionFactory: both the pooling of connections and the XA enlistment. Such a ConnectionManager would delegate to the javax.transaction.TransactionManager for the actual transactional management of XA resources, but it still needs to do a lot of quite tricky work. And it needs to do the entire connection pooling! I would argue that this outside of the scope of Spring. One of the nice things about the JTA/JCA spec combo is that they allow to separate the transaction manager from the connection pool completely, even in case of an XA-aware pool. So there could be independent transaction manager implementations and XA connection pool implementations, collaborating with each other through standard interfaces. JOTM and XAPool are good example for this separation. But there should be a better and more general pool than XAPool: one working with the JCA contracts, thus being able to handle any kind of resource rather than just JDBC Connections. I would love to see such a project emerge, maybe at Jakarta Commons or as independent SourceForge project. BTW, Tyrex (http://tyrex.sourceforge.net) offers a transaction manager plus a generic JCA-based connection pool in a combo. Unfortunately, it's virtually dead. But it could be an inspiration for an implementation of such a generic connection pool. Actually, there is a need for such a generic pool in Geronimo, where (as far as I know) JOTM will be used as transaction manager. They can't just use XAPool there, because they need to be JCA-compliant too. I wonder which pool they are gonna use there... third-party or Geronimo-specific? In any case, it should be a reusable component, so it's probably worth checking out. Juergen -----Original Message----- From: Thierry TEMPLIER [mailto:te...@ya...] Sent: Wednesday, April 13, 2005 12:59 PM To: Dmitriy Kopylenko; Juergen Hoeller Cc: Thierry TEMPLIER Subject: Re: [Springframework-developer] JCA support Hi Dmitriy and Juerguen, I think that it's feasible but it's not simple... We must support JCA 1.0 / 1.5 and the version 1.5 brings some important improvments in the SPI side! and manage the interactions with JCA SPI... In any case, I'm interesting to look at this and send you my code like for JCA CCI ;-) So we will see at this moment if it's in the scope of Spring JCA. Are you interested with this idea? Firstly, Dmitriy, I will debug and improve the beginned project around JOTM and take you up to date with my work... I have looked at the code you put in the Spring Main, Juerguen and congratulations it really improves and simplifies my work ;-) I will update the JCA sample and the documentation. Do you a date planned for the version 1.2 RC2 of Spring (when the documentation must be ready...)? Nevertheless, I have a remark about the record management. I see in the book "J2EE Connector Architecture and Enterprise Application Integration" a "strange" use of record with the JCA SAP connector. I have never used this connector but I will work on JCO the native (non JCA compliant) connector of SAP. Here is an extract of the code of the book: "Connection connection=...; Interaction interaction=...; MappedRecord inputRecord=recordFactory.createMappedRecord("BAPI_BANK_CREATE"); ResultSet input=(ResultSet)inputRecord.get("import"); //some works on the input record to put datas //for example input.updateString("BANK_CTRY",someValue); interaction.execute(null,inputRecord); ResultSet output=(ResultSet)inputRecord.get("export"); ..." That was the aim of my second flag (useInputAsOutput) for the two execute methods of CCI. If you work directly on records, there is no problem but it isn't possible if you use RecordCreator/RecordExtractor because records are managed by the Ccitemplate class. Perhaps I'm wrong. If not, a flag could be added on the CciTemplate for this case... Cheers, Thierry > It would be very desirable to see the JCA SPIs > implemented to allow > deploy and use of resource adapter in say a > standalone Servlet container > + standalone transaction coordinator (JOTM) and have > a full XA support > with 2PC (for example doing an IMS transaction + > Oracle operation in one > global TX context)! Is it really feasible? > > Dmitriy. Take a look at my blog: http://templth.blogspot.com/ ____________________________________________________________________________ _______________________ Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis. A télécharger gratuitement sur http://fr.messenger.yahoo.com |
|
From: Steve L. <spi...@ya...> - 2005-04-13 16:06:52
|
Hello Juergen, I've recently begun a project (not hosted anywhere yet) for a JCA container. It's in the very early stages, but it uses Commons Pool for the pooling. I've begun to talk with Thierry so maybe we can throw something together that's useful. Currently I am in the early stages of testing my container against the local transaction JBoss JDBC adapter. But basically I'd like to say something like: Container.registerAdapter(AdapterInfo); Then once it's registered, call Container.getDataSource() or Container.getConnectionFactory() Something very simple that hides all that complexity, as much as possible. Thanks, Steve __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail |
|
From: Juergen H. <ju...@in...> - 2005-04-13 16:51:09
|
Hi over here too, Steve! I've already briefly responded on the user list. I'll go a bit further here... The core of a JCA container is the implementation of the javax.resource.spi.ConnectionManager interface. This is what the ManagedConnectionFactory of a concrete JCA connector needs to receive to be able to work in a managed fashion. Everything else essentially comes with the connector itself. This ConnectionManager implementation can either be a simple connection pool (for JCA's non-managed mode) or a full-fledged manager of the overall JCA service contracts (for JCA's managed mode, in particular including XA transaction management). For the latter mode, it has to collaborate with a javax.transaction.TransactionManager. In a Spring context, such a ConnectionManager would simply be defined as bean. Each JCA connector would then be set up with Spring's existing LocalConnectionFactoryBean, taking a ManagerConnectionFactory instance and a ConnectionManager instance and exposing the connector's native ConnectionFactory (e.g. a JDBC DataSource or CCI ConnectionFactory). So for a Spring environment, we don't actually need a JCA *container* in the sense that it manages the setup of the connectors. All we need is a JCA ConnectionManager implementation that is XA-capable and able to interact with a given javax.transaction.TransactionManager instance. If the ConnectionManager is defined as bean, it could simply receive the JTA TransactionManager as bean reference. This would allow us to define all involved components as Spring beans: the TransactionManager, the ConnectionManager, the ManagedConnectionFactory of each connector, and the native ConnectionFactory for each connector. Note that in the above configuration model, it's all objects: no static accessors or static state anywhere, it's all in instances. A ConnectionManager like the above would be completely generic in that it could work with any JCA connector and with any JTA implementation. Furthermore, it doesn't require any Spring dependencies: as long as the ConnectionManager follows JavaBean conventions, it can easily be used in a Spring environment despite being a completely separate component. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Steve Lewis Sent: Wednesday, April 13, 2005 6:07 PM To: Spr...@li... Subject: [Springframework-developer] Re: JCA support Hello Juergen, I've recently begun a project (not hosted anywhere yet) for a JCA container. It's in the very early stages, but it uses Commons Pool for the pooling. I've begun to talk with Thierry so maybe we can throw something together that's useful. Currently I am in the early stages of testing my container against the local transaction JBoss JDBC adapter. But basically I'd like to say something like: Container.registerAdapter(AdapterInfo); Then once it's registered, call Container.getDataSource() or Container.getConnectionFactory() Something very simple that hides all that complexity, as much as possible. Thanks, Steve __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Dmitriy K. <dko...@ru...> - 2005-04-11 12:18:41
|
Thierry TEMPLIER wrote: >I see too that the JCA sample is in cvs but, I think >that it doesn't use classes of the main sources. I >will refactor it to use it. >To finish, do you want that I update the documentation >of the JCA support with your improvements? >Cheers, >Thierry > > > I did check in the sample yesterday. If you refactor it, I'll update it in CVS. And yes, updated documentation would be nice to have too :-) Dmitriy. |
