Subject: Re: Is Spring transaction management worthusing? - msg#00527

Previous Message by Date: click to view message preview

Re: looking up local or remote objects w/o changing client code

Keith Donald wrote: Bruce, You should never have to change the client code when you switch between a proxy to an EJB-fronted façade of a POJO service or the POJO service itself. In either case, you always want to inject the business interface of the said service to your clients, irrelevant of whether that interface is backed by EJB. That's one of the main benefits of IoC. If you'd prefer to use "dependency lookup" as opposed to "dependency injection", you can grab the service interface out of the context using applicationContext.getBean(serviceName). In that case you're still independent of whether that service is local, remote, or is or is not backed by EJB; you should just get back an object castable to the service's business interface. I still prefer "dependency injection"-style IoC to lookup, as with a context lookup your client code is now dependent on a Spring application context. Alternatively, you could inject your own service locator interface that wraps a context lookup if you prefer a lookup strategy but not a dependency on Spring. Here are some examples: Proxy to a local EJB (see the SimpleRemote flavor for a remote EJB): <bean id=“ejbServiceProxy" class=“org.springframework.ejb.access.LocalStatelessSessionProxyFactoryBean" <property name="jndiName"> <value>myEjb</value> </property> <property name="businessInterface"> <value>com.mycompany.domain.MyBusinessInterface</value> </property> </bean> Plain old POJO direct reference: <bean id="service" class="com.mycompany.domain.MyBusinessServiceImpl"> <property> ... </property> </bean> Client of services: <bean id="myClient" class="com.mycompany.client.MyClient"> <property name="myService"><ref bean="service"></property> </bean> To use the EJB proxy, simply replace the client reference to the "service" bean with the reference to "ejbServiceProxy" -- a matter of configuration; since both implement the same business interface, the client doesn't know the difference. You may want different context files for the different sets of configurations, particularly if your client's lookup each service by a common, well-known name. Keith -----Original Message----- From: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Bruce Snyder Sent: Thursday, May 27, 2004 8:01 PM To: springframework-user@xxxxxxxxxxxxxxxxxxxxx Subject: [Springframework-user] looking up local or remote objects w/o changing client code I am developing all business logic in POJOs and wrapping them in SLSBs when they need to run in a J2EE container. But there are also times where that POJO needs to be instantiated in the J2SE world. I don't want to change the client code depending on whether a service will be local or remote. I want my client code to be able to call: ServiceFactory.getBean( "nameOfBean" ); and get back the real impl if it's local or a dynamic remote proxy if it's remote. I've got the dynamic remote proxies working great with Spring, but only if the client code calls: BlahService service = BlahServiceUtil.getHome().create(); How can I get Spring to distinguish a local lookup from a remote lookup and allow my client code to remain the same? Colin, Oliver, Keith, Thank you all for responding to me. The same theme is appearing throughout each response - the notion of the client code shouldn't change no matter what the impl behind the scenes. This is one of the big reasons I chose to use Spring so I'm very aware of this. What I failed to understand was how to achieve this when a service could be either a remote EJB or a local POJO. Last night I figured it out and fixed my mistakes. Thank you very much for the feedback and the examples. Bruce -- perl -e 'print unpack("u30","<0G)U8V4\\@4VYY9&5R\\"F9E<G)E=\\$\\!F<FEI+F-O;0\\`\\`");' The Castor Project http://www.castor.org/ Apache Geronimo http://incubator.apache.org/projects/geronimo.html ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id?66&op=click

Next Message by Date: click to view message preview

RE: Is Spring transaction management worthusing?

Well, i meant no malice. I HAVE read the documentation. I HAVE used the transaction management and liked it quite well. However, i am new to spring and I was simply looking to find out what the REAL story was on what i was being told. So, what better place to go to than the knowledgeable? Also, the prior posts that i read were specific problems with implementations and i certainly read that they were resolved. I was just looking to see if there were any other issues related to those TYPE of problems that would cause someone to take issue with your transaction management. If you noticed... my final question was "Is this an accurate portrayal?". Also, why do you have a problem with people asking these types of questions on a "public forum". That's silliness imo. We field questions like this on the ibatis list without problem. Besides, if the rumor is in fact floating around, what better place is there to resolve it? I appreciate all the responses and i think it clears up my question quite well. Thank You. Brandon Goodin -----Original Message----- From: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx]On Behalf Of jürgen höller [werk3AT] Sent: Saturday, May 29, 2004 11:23 AM To: springframework-user@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [Springframework-user] Is Spring transaction management worthusing? Brandon, I think it's pretty clear from our docs and samples that Spring's JtaTransactionManager itself works just nicely in a container-independent fashion - in typical usage scenarios where you could use a plain JTA javax.transaction.UserTransaction too. We have always clarified this when a corresponding question has popped up on the forums. As Dmitriy has outlined, you just need container-specific configuration for more advanced usage, namely transaction suspension and Hibernate cache completion callbacks. The simple reason for this is that you need the JTA javax.transaction.TransactionManager to suspend/resume transactions and register transaction synchronizations; the UserTransaction interface does not support that functionality. Unfortunately, J2EE does not specify how to access the JTA TransactionManager, just the common JNDI location of the JTA UserTransaction - so the lookup of the JTA TransactionManager has to be container-specific. This is the case with Hibernate (see TransactionManagerLookup), this is the case with Spring, this is the case with any such tool. So for typical usages, simple declare Spring's JtaTransactionManager without any properties. Just for transaction suspension, specify a "transactionManagerName" (JNDI location of the JTA TransactionManager) or a "transactionManager" reference (from JndiObjectFactoryBean, to centrally define the JNDI location; or from a special lookup strategy, like JotmFactoryBean or WebSphereTransactionManagerFactoryBean). ----- For Hibernate cache completion callbacks with JTA, you need to specify a corresponding TransactionManagerLookup in the Hibernate properties. As an alternative, Spring allows you to pass a JTA TransactionManager into LocalSessionFactoryBean's "jtaTransactionManager" property, to reuse a centrally defined TransactionManager reference that can be shared with JtaTransactionManager's "transactionManager" property. Note that you'll also get proper Hibernate cache completion callbacks without such a container-specific TransactionManagerLookup, as long as you use Spring's transaction management - because Spring has its own transaction synchronization mechanism. So even for proper Hibernate callbacks with Spring, there is typically no need for container-specific JTA configuration; a plain JtaTransactionManager definition is fine. That said, there is an issue with WebLogic/WebSphere and Hibernate, which is also what keeps popping up on our forums: Those containers have very rigid JTA implementations that don't allow any access to a transactional JDBC Connection after transaction completion. Because of this, Spring's standard Hibernate cache completion callback causes a warning in the logs; an additional container-specific Hibernate TransactionManagerLookup avoids this. ----- All things considered, to the best of my knowledge, Spring's JTA support is as strong as can be. It even includes special support for Hibernate/JTA integration, which addresses typical Hibernate issues. Spring cannot offer more than it does already, as JTA simply doesn't specify more functionality. It cannot simplify JTA configuration either, as the remaining limits are caused by JTA itself. In particular, Spring's transaction management offers all 6 propagation behavior types that EJB CMT defines (REQUIRED, REQUIRES_NEW, etc). In the case of JTA, REQUIRES_NEW and NOT_SUPPORTED can just be offered if the javax.transaction.TransactionManager is accessible, which requires a container-specific lookup - a J2EE/JTA issue that is not caused by Spring, and faced by all tools that work with JTA in a J2EE environment. Side note: Spring's other transaction strategies, namely DataSourceTransactionManager, HibernateTransactionManager and JdoTransactionManager, offer all 6 propagation behavior types too - without any container-specific configuration. Furthermore, the former two also offer per-transaction isolation levels, which is a concept not supported by JTA in the first place. Some transaction strategies support "read-only transactions" too, for example HibernateTransactionManager. ----- Please, before you quote anonymous sources that say that "JTA support is poor" and speculate about problems "when containers upgrade" - without specific problems, and on a public user forum of the product that you're questioning -, spend a few minutes checking your facts. A look into the docs/javadocs - or a detailed read of answers to those forum questions you referred to - would have revealed that those assumptions are obviously wrong. So, now that we've removed that obstacle: If you've got any further questions regarding Spring's transaction support (*after* a look at the docs), feel free to ask me: be it about usage patterns, implementation internals, issues with specific persistence tools, or issues with specific J2EE containers. I'll also be happy to clarify any issues regarding Spring's support for iBATIS SQL Maps, which is obviously of interest to you :-) Juergen ________________________________ Von: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx im Auftrag von Dmitriy Kopylenko Gesendet: Sa 29.05.2004 05:44 An: springframework-user@xxxxxxxxxxxxxxxxxxxxx Betreff: Re: [Springframework-user] Is Spring transaction management worthusing? Brandon, thanks for your reply. Let me briefly say that Spring provides completely generic implementation of PlatformTransactionManager namely JtaTransactionManager which handles most of the use cases for generic J2EE global transactions such as distributed transactions and managing transactions on J2EE connector (JCA resource adapter). In order to support transaction suspension (REQUIRES_NEW, NOT_SUPPORTED), Spring needs to get hold of JTA TransactionManager which is an internal JTA object and its location is not specified by J2EE spec. and is individual for each J2EE container. Spring provides two FactoryBean implementations for JOTM and WebSphere to obtain the JtaTransactionManager for respective JTA implementations, as static accessor methods are required to get hold of TransactionManager for both JOTM and WebSphere... I'm not sure about a potential problem with containers upgrade. I'll let Juergen, Rod and others comment on this. Regards, Dmitriy. Brandon Goodin wrote: I'm just trying to find out if there are any serious problems with Transaction Management. Looking into the archives it seems the chief complaint is that spring has to provide specific container support for JTA Transaction Management. That could pose a problem as containers upgrade. Projects using spring would need to make sure that Spring has support for their container before proceeding with a point upgrade. This is in line with what I heard from another source. Is this an accurate portrayal? Brandon Goodin ________________________________ From: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Dmitriy Kopylenko Sent: Friday, May 28, 2004 8:04 PM To: springframework-user@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [Springframework-user] Is Spring transaction management worthusing? Brandon, I'm sorry, but from your email it's not clear what you mean. You said: "in general I've heard that the JTA support is poor" I just what to find out from whom you heard that statement? In general I could tell you one thing - Spring's JTA support is not poor at all ;-) Regards, Dmitriy. Brandon Goodin wrote: Why are you asking me a question that I have already answered? Read my email and you may find the answer to your question. ;-) Brandon ________________________________ From: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Dmitriy Kopylenko Sent: Friday, May 28, 2004 7:34 PM To: springframework-user@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [Springframework-user] Is Spring transaction management worthusing? I'm just curious - where did you hear that "the JTA support is poor" and what are the specific areas of this "poor support"? Dmitriy. Brandon Goodin wrote: Specifically, I have nothing. But, in general I've heard that the JTA support is poor. I'm just curious if anyone can give me a clear blow for blow on where the Transaction capabilities are strong and where they need some work. Brandon Goodin -----Original Message----- From: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Nadeem Bitar Sent: Friday, May 28, 2004 5:30 PM To: springframework-user@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [Springframework-user] Is Spring transaction management worthusing? On ?, 2004-05-28 at 18:11 -0700, Brandon Goodin wrote: I've heard that there are issues with the Spring transaction management. Can someone explain to me the pros and cons of Spring's management of transactions? Which issues? because I having been using it for a year without any problem. Brandon Goodin ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id66&op=click _______________________________________________ Springframework-user mailing list Springframework-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/springframework-user ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Springframework-user mailing list Springframework-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/springframework-user ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id?66&op=click _______________________________________________ Springframework-user mailing list Springframework-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/springframework-user ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id?66&op=click

Previous Message by Thread: click to view message preview

Is Spring transaction management worth using?

I’ve heard that there are issues with the Spring transaction management. Can someone explain to me the pros and cons of Spring’s management of transactions?   Brandon Goodin

Next Message by Thread: click to view message preview

RE: Is Spring transaction management worthusing?

Well, i meant no malice. I HAVE read the documentation. I HAVE used the transaction management and liked it quite well. However, i am new to spring and I was simply looking to find out what the REAL story was on what i was being told. So, what better place to go to than the knowledgeable? Also, the prior posts that i read were specific problems with implementations and i certainly read that they were resolved. I was just looking to see if there were any other issues related to those TYPE of problems that would cause someone to take issue with your transaction management. If you noticed... my final question was "Is this an accurate portrayal?". Also, why do you have a problem with people asking these types of questions on a "public forum". That's silliness imo. We field questions like this on the ibatis list without problem. Besides, if the rumor is in fact floating around, what better place is there to resolve it? I appreciate all the responses and i think it clears up my question quite well. Thank You. Brandon Goodin -----Original Message----- From: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx]On Behalf Of jürgen höller [werk3AT] Sent: Saturday, May 29, 2004 11:23 AM To: springframework-user@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [Springframework-user] Is Spring transaction management worthusing? Brandon, I think it's pretty clear from our docs and samples that Spring's JtaTransactionManager itself works just nicely in a container-independent fashion - in typical usage scenarios where you could use a plain JTA javax.transaction.UserTransaction too. We have always clarified this when a corresponding question has popped up on the forums. As Dmitriy has outlined, you just need container-specific configuration for more advanced usage, namely transaction suspension and Hibernate cache completion callbacks. The simple reason for this is that you need the JTA javax.transaction.TransactionManager to suspend/resume transactions and register transaction synchronizations; the UserTransaction interface does not support that functionality. Unfortunately, J2EE does not specify how to access the JTA TransactionManager, just the common JNDI location of the JTA UserTransaction - so the lookup of the JTA TransactionManager has to be container-specific. This is the case with Hibernate (see TransactionManagerLookup), this is the case with Spring, this is the case with any such tool. So for typical usages, simple declare Spring's JtaTransactionManager without any properties. Just for transaction suspension, specify a "transactionManagerName" (JNDI location of the JTA TransactionManager) or a "transactionManager" reference (from JndiObjectFactoryBean, to centrally define the JNDI location; or from a special lookup strategy, like JotmFactoryBean or WebSphereTransactionManagerFactoryBean). ----- For Hibernate cache completion callbacks with JTA, you need to specify a corresponding TransactionManagerLookup in the Hibernate properties. As an alternative, Spring allows you to pass a JTA TransactionManager into LocalSessionFactoryBean's "jtaTransactionManager" property, to reuse a centrally defined TransactionManager reference that can be shared with JtaTransactionManager's "transactionManager" property. Note that you'll also get proper Hibernate cache completion callbacks without such a container-specific TransactionManagerLookup, as long as you use Spring's transaction management - because Spring has its own transaction synchronization mechanism. So even for proper Hibernate callbacks with Spring, there is typically no need for container-specific JTA configuration; a plain JtaTransactionManager definition is fine. That said, there is an issue with WebLogic/WebSphere and Hibernate, which is also what keeps popping up on our forums: Those containers have very rigid JTA implementations that don't allow any access to a transactional JDBC Connection after transaction completion. Because of this, Spring's standard Hibernate cache completion callback causes a warning in the logs; an additional container-specific Hibernate TransactionManagerLookup avoids this. ----- All things considered, to the best of my knowledge, Spring's JTA support is as strong as can be. It even includes special support for Hibernate/JTA integration, which addresses typical Hibernate issues. Spring cannot offer more than it does already, as JTA simply doesn't specify more functionality. It cannot simplify JTA configuration either, as the remaining limits are caused by JTA itself. In particular, Spring's transaction management offers all 6 propagation behavior types that EJB CMT defines (REQUIRED, REQUIRES_NEW, etc). In the case of JTA, REQUIRES_NEW and NOT_SUPPORTED can just be offered if the javax.transaction.TransactionManager is accessible, which requires a container-specific lookup - a J2EE/JTA issue that is not caused by Spring, and faced by all tools that work with JTA in a J2EE environment. Side note: Spring's other transaction strategies, namely DataSourceTransactionManager, HibernateTransactionManager and JdoTransactionManager, offer all 6 propagation behavior types too - without any container-specific configuration. Furthermore, the former two also offer per-transaction isolation levels, which is a concept not supported by JTA in the first place. Some transaction strategies support "read-only transactions" too, for example HibernateTransactionManager. ----- Please, before you quote anonymous sources that say that "JTA support is poor" and speculate about problems "when containers upgrade" - without specific problems, and on a public user forum of the product that you're questioning -, spend a few minutes checking your facts. A look into the docs/javadocs - or a detailed read of answers to those forum questions you referred to - would have revealed that those assumptions are obviously wrong. So, now that we've removed that obstacle: If you've got any further questions regarding Spring's transaction support (*after* a look at the docs), feel free to ask me: be it about usage patterns, implementation internals, issues with specific persistence tools, or issues with specific J2EE containers. I'll also be happy to clarify any issues regarding Spring's support for iBATIS SQL Maps, which is obviously of interest to you :-) Juergen ________________________________ Von: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx im Auftrag von Dmitriy Kopylenko Gesendet: Sa 29.05.2004 05:44 An: springframework-user@xxxxxxxxxxxxxxxxxxxxx Betreff: Re: [Springframework-user] Is Spring transaction management worthusing? Brandon, thanks for your reply. Let me briefly say that Spring provides completely generic implementation of PlatformTransactionManager namely JtaTransactionManager which handles most of the use cases for generic J2EE global transactions such as distributed transactions and managing transactions on J2EE connector (JCA resource adapter). In order to support transaction suspension (REQUIRES_NEW, NOT_SUPPORTED), Spring needs to get hold of JTA TransactionManager which is an internal JTA object and its location is not specified by J2EE spec. and is individual for each J2EE container. Spring provides two FactoryBean implementations for JOTM and WebSphere to obtain the JtaTransactionManager for respective JTA implementations, as static accessor methods are required to get hold of TransactionManager for both JOTM and WebSphere... I'm not sure about a potential problem with containers upgrade. I'll let Juergen, Rod and others comment on this. Regards, Dmitriy. Brandon Goodin wrote: I'm just trying to find out if there are any serious problems with Transaction Management. Looking into the archives it seems the chief complaint is that spring has to provide specific container support for JTA Transaction Management. That could pose a problem as containers upgrade. Projects using spring would need to make sure that Spring has support for their container before proceeding with a point upgrade. This is in line with what I heard from another source. Is this an accurate portrayal? Brandon Goodin ________________________________ From: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Dmitriy Kopylenko Sent: Friday, May 28, 2004 8:04 PM To: springframework-user@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [Springframework-user] Is Spring transaction management worthusing? Brandon, I'm sorry, but from your email it's not clear what you mean. You said: "in general I've heard that the JTA support is poor" I just what to find out from whom you heard that statement? In general I could tell you one thing - Spring's JTA support is not poor at all ;-) Regards, Dmitriy. Brandon Goodin wrote: Why are you asking me a question that I have already answered? Read my email and you may find the answer to your question. ;-) Brandon ________________________________ From: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Dmitriy Kopylenko Sent: Friday, May 28, 2004 7:34 PM To: springframework-user@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [Springframework-user] Is Spring transaction management worthusing? I'm just curious - where did you hear that "the JTA support is poor" and what are the specific areas of this "poor support"? Dmitriy. Brandon Goodin wrote: Specifically, I have nothing. But, in general I've heard that the JTA support is poor. I'm just curious if anyone can give me a clear blow for blow on where the Transaction capabilities are strong and where they need some work. Brandon Goodin -----Original Message----- From: springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:springframework-user-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Nadeem Bitar Sent: Friday, May 28, 2004 5:30 PM To: springframework-user@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [Springframework-user] Is Spring transaction management worthusing? On ?, 2004-05-28 at 18:11 -0700, Brandon Goodin wrote: I've heard that there are issues with the Spring transaction management. Can someone explain to me the pros and cons of Spring's management of transactions? Which issues? because I having been using it for a year without any problem. Brandon Goodin ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id66&op=click _______________________________________________ Springframework-user mailing list Springframework-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/springframework-user ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Springframework-user mailing list Springframework-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/springframework-user ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id?66&op=click _______________________________________________ Springframework-user mailing list Springframework-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/springframework-user ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id?66&op=click