Comments on: Spring Framework Certified on WebSphere http://blog.springsource.com/main/2007/06/21/spring-framework-certified-on-websphere/ The voice of SpringSource Thu, 21 Aug 2008 01:34:32 +0000 http://wordpress.org/?v=2.0.11 by: Revue de Presse Xebia par J2EE, Agilité et SOA : Le blog de Xebia France http://blog.springsource.com/main/2007/06/21/spring-framework-certified-on-websphere/#comment-58561 Mon, 29 Oct 2007 17:10:52 +0000 http://blog.springsource.com/main/2007/06/21/spring-framework-certified-on-websphere/#comment-58561 [...] Support officiel de Websphere, fruit de la collaboration d’Interface21 avec le lab d’IBM Hursley, avec notamment l’introduction du WebSphereUowTransactionManager [...] […] Support officiel de Websphere, fruit de la collaboration d'Interface21 avec le lab d'IBM Hursley, avec notamment l'introduction du WebSphereUowTransactionManager […]

]]> by: Chris Moon http://blog.springsource.com/main/2007/06/21/spring-framework-certified-on-websphere/#comment-38606 Wed, 08 Aug 2007 15:42:46 +0000 http://blog.springsource.com/main/2007/06/21/spring-framework-certified-on-websphere/#comment-38606 Did the certification include Spring MVC and Spring Portlet MVC running on WebSphere Portal? Did the certification include Spring MVC and Spring Portlet MVC running on WebSphere Portal?

]]> by: Interface21 Team Blog » Java EE 6 Gets it Right http://blog.springsource.com/main/2007/06/21/spring-framework-certified-on-websphere/#comment-31973 Tue, 03 Jul 2007 20:27:28 +0000 http://blog.springsource.com/main/2007/06/21/spring-framework-certified-on-websphere/#comment-31973 [...] Again, great stuff. The fallacy that technologies shipped with the platform were "better integrated" with the server infrastructure than these "interesting and useful technologies" was long used by server vendors to confuse users and prevent innovation. (Fortunately, nearly all of them have long since stopped doing so: for example, consider IBM's part in the certification of Spring on WebSphere). [...] […] Again, great stuff. The fallacy that technologies shipped with the platform were "better integrated" with the server infrastructure than these "interesting and useful technologies" was long used by server vendors to confuse users and prevent innovation. (Fortunately, nearly all of them have long since stopped doing so: for example, consider IBM's part in the certification of Spring on WebSphere). […]

]]> by: Johan Eltes http://blog.springsource.com/main/2007/06/21/spring-framework-certified-on-websphere/#comment-31102 Sat, 30 Jun 2007 12:16:12 +0000 http://blog.springsource.com/main/2007/06/21/spring-framework-certified-on-websphere/#comment-31102 Many of our customers are suffering from the Local Transaction Scoping in WebSphere 5 . There are some articles on it - sorry for not having it at hand. In short, WebSphere does not allow the developer to design the use of transaction demarcation often required to minimize the lease time of none-transactional (read-only) usage of database connections. With most J2EE-compliant application servers (I'm not aware of any exception, except for WebSphere), running a request outside of an active JTA transaction, makes jdbcConn.close() make the connection immediately available to serve concurrent requests. Unfortunately, WebSphere creates a local transaction scope for the complete web request, which forces the lease to of connections to last for the complete (none-transactional) web request. Imagine a Struts action forwarding to the next etc... Many internet-facing web applications have ratio for transactional / none-transactional web requests of 20-to-1. Optimization of connection lease time becomes a critical factor for scalability. On behalf of one of the worlds largest companies, I filed a request to IBM for adding a configuration option to disable the local transaction scoping feature. The reason for having it there is - according to the IBM technician - to be able to help the developer avoid leaking connections. If the developer forgets to close a connection within a read-only DAO operation, the local transaction scoping allows websphere to close all connections that was created during the scope. This is however not consistently implemented in WebSphere. If the same DAO operation is invoked from an MDB, the DAO will leak connections. This behavior only applies to Sharable datasources. Unsharable ones are not "trapped" by the local transaction scoping mechanism - and thus immediately returned to the outer connection pool for re-use by concurrent threads. The solution is then to configure two data sources instead of one - a Sharable to use for transactional requests and a Unsharable for read-only requests. There is - however - no fully general way for a DAO operation to know which one to use - i.e. to know if the operation is executing within an active JTA transaction or not. If the application team can standardize on bean-managed transaction demarcation - which is the typical Spring scenario - DAO operation could query the transaction status of the UserTransaction. This will however require the DAO operation to have a UserTransaction injected, which breaks the value of the portable platform abstraction I expect from my Spring usage. My code will not run out-of-container, unless I have a transaction platform abstraction that uses UserTransaction as the api. Spring doesn't. It also doesn't provide a way of querying the transaction status. In this sense, Springs platform abstraction is not semantically complete. Having the UserTransaction interface as the api of a portable platform abstraction, isn't semantically complete either, which was of cause the reason for Spring to role their own api. Where am I heading, the reader may wonder. On my wish list for making Spring integrating seamlessly with websphere, I would request from IBM to add the possibility to disable local transaction scoping for Sharable datasources. At some customers, we hav had to role our own transaction abstraction based on the UserTransaction interface, with out-of-container transaction manager for integration testing, and all that comes with it. This has been integrated into Spring DI, but we would definitely have preferred to use what Spring provides in terms of transaction platform abstraction. Many of our customers are suffering from the Local Transaction Scoping in WebSphere 5 . There are some articles on it - sorry for not having it at hand. In short, WebSphere does not allow the developer to design the use of transaction demarcation often required to minimize the lease time of none-transactional (read-only) usage of database connections. With most J2EE-compliant application servers (I'm not aware of any exception, except for WebSphere), running a request outside of an active JTA transaction, makes jdbcConn.close() make the connection immediately available to serve concurrent requests. Unfortunately, WebSphere creates a local transaction scope for the complete web request, which forces the lease to of connections to last for the complete (none-transactional) web request. Imagine a Struts action forwarding to the next etc… Many internet-facing web applications have ratio for transactional / none-transactional web requests of 20-to-1. Optimization of connection lease time becomes a critical factor for scalability. On behalf of one of the worlds largest companies, I filed a request to IBM for adding a configuration option to disable the local transaction scoping feature. The reason for having it there is - according to the IBM technician - to be able to help the developer avoid leaking connections. If the developer forgets to close a connection within a read-only DAO operation, the local transaction scoping allows websphere to close all connections that was created during the scope. This is however not consistently implemented in WebSphere. If the same DAO operation is invoked from an MDB, the DAO will leak connections. This behavior only applies to Sharable datasources. Unsharable ones are not "trapped" by the local transaction scoping mechanism - and thus immediately returned to the outer connection pool for re-use by concurrent threads. The solution is then to configure two data sources instead of one - a Sharable to use for transactional requests and a Unsharable for read-only requests. There is - however - no fully general way for a DAO operation to know which one to use - i.e. to know if the operation is executing within an active JTA transaction or not. If the application team can standardize on bean-managed transaction demarcation - which is the typical Spring scenario - DAO operation could query the transaction status of the UserTransaction. This will however require the DAO operation to have a UserTransaction injected, which breaks the value of the portable platform abstraction I expect from my Spring usage. My code will not run out-of-container, unless I have a transaction platform abstraction that uses UserTransaction as the api. Spring doesn't. It also doesn't provide a way of querying the transaction status. In this sense, Springs platform abstraction is not semantically complete. Having the UserTransaction interface as the api of a portable platform abstraction, isn't semantically complete either, which was of cause the reason for Spring to role their own api. Where am I heading, the reader may wonder. On my wish list for making Spring integrating seamlessly with websphere, I would request from IBM to add the possibility to disable local transaction scoping for Sharable datasources. At some customers, we hav had to role our own transaction abstraction based on the UserTransaction interface, with out-of-container transaction manager for integration testing, and all that comes with it. This has been integrated into Spring DI, but we would definitely have preferred to use what Spring provides in terms of transaction platform abstraction.

]]> by: Juergen Hoeller http://blog.springsource.com/main/2007/06/21/spring-framework-certified-on-websphere/#comment-30896 Fri, 29 Jun 2007 13:26:40 +0000 http://blog.springsource.com/main/2007/06/21/spring-framework-certified-on-websphere/#comment-30896 WebSphereUowTransactionManager, building on IBM's new UOWManager API, is only supported on WebSphere 6.0.2.19 and 6.1.0.9 . On WebSphere 5.1, the best you can do is to keep using Spring's standard JtaTransactionManager in combination with WebSphereTransactionManagerFactoryBean (which has already been available in Spring 1.2 and 2.0; if you don't need transaction suspension, stick with a plain JtaTransactionManager). That said, note that Spring 2.1 still supports WebSphere 5.1 in general, since Spring 2.1 remains compatible with JDK 1.4.2 and J2EE 1.3 (as far as possible). WebSphereUowTransactionManager, building on IBM's new UOWManager API, is only supported on WebSphere 6.0.2.19 and 6.1.0.9 . On WebSphere 5.1, the best you can do is to keep using Spring's standard JtaTransactionManager in combination with WebSphereTransactionManagerFactoryBean (which has already been available in Spring 1.2 and 2.0; if you don't need transaction suspension, stick with a plain JtaTransactionManager).

That said, note that Spring 2.1 still supports WebSphere 5.1 in general, since Spring 2.1 remains compatible with JDK 1.4.2 and J2EE 1.3 (as far as possible).

]]> by: PM http://blog.springsource.com/main/2007/06/21/spring-framework-certified-on-websphere/#comment-30029 Tue, 26 Jun 2007 00:45:31 +0000 http://blog.springsource.com/main/2007/06/21/spring-framework-certified-on-websphere/#comment-30029 Is WebSphereUowTransactionManager supported on WebSphere 5.1? If so, do i need get the latest release of spring to use the transaction manager. PM Is WebSphereUowTransactionManager supported on WebSphere 5.1? If so, do i need get the latest release of spring to use the transaction manager.

PM

]]> by: links for 2007-06-22 » SDLC Blog http://blog.springsource.com/main/2007/06/21/spring-framework-certified-on-websphere/#comment-30004 Mon, 25 Jun 2007 22:35:41 +0000 http://blog.springsource.com/main/2007/06/21/spring-framework-certified-on-websphere/#comment-30004 [...] Interface21 Team Blog » Spring Framework Certified on WebSphere Rod Johnson explains the work done in the Spring WAS certification. (tags: IBM WAS springframework) [...] […] Interface21 Team Blog » Spring Framework Certified on WebSphere Rod Johnson explains the work done in the Spring WAS certification. (tags: IBM WAS springframework) […]

]]> by: Julien Dubois http://blog.springsource.com/main/2007/06/21/spring-framework-certified-on-websphere/#comment-28728 Thu, 21 Jun 2007 14:07:51 +0000 http://blog.springsource.com/main/2007/06/21/spring-framework-certified-on-websphere/#comment-28728 Nicolas, I'm happy to see you made it to SpringOne once more! And I can't imagine any manager in your company in such a situation either :-) Nicolas, I'm happy to see you made it to SpringOne once more! And I can't imagine any manager in your company in such a situation either :-)

]]> by: nicolas de loof http://blog.springsource.com/main/2007/06/21/spring-framework-certified-on-websphere/#comment-28690 Thu, 21 Jun 2007 11:25:47 +0000 http://blog.springsource.com/main/2007/06/21/spring-framework-certified-on-websphere/#comment-28690 I'm also at springone'07 and sit by chance jut behind Rod during keynote, when he typed this blog entry. Really funny to see a 10M$ company CEO and all his staff working with laptop on knees for a strategic announcement on IBM collaboration. I can't imagine my company bosses in such a situation. Is this the silicon valley way of life ? Thank for great sessions at Spring-one, and especially this incredible duck-typing demo. I'm also at springone'07 and sit by chance jut behind Rod during keynote, when he typed this blog entry. Really funny to see a 10M$ company CEO and all his staff working with laptop on knees for a strategic announcement on IBM collaboration. I can't imagine my company bosses in such a situation. Is this the silicon valley way of life ?

Thank for great sessions at Spring-one, and especially this incredible duck-typing demo.

]]>