RE: Anyone experience any problems with JDBC Oracle drivers and JDK 1.3.1 with connection pooling?
I'm using the Oracle Type-4 driver (downloaded from Oracle) but am using Oracle8.1.6 w/Orion 1.5.2 JDK 1.3.1 W2K Server as well and haven't had a problem with connection pools or CLOBs. It is my understanding that 8.1.7 isn't as stable as 8.1.6 though. -Original Message-From: HyungKee Hwang [mailto:[EMAIL PROTECTED]]Sent: Thursday, July 26, 2001 5:45 PMTo: Orion-InterestSubject: RE: Anyone experience any problems with JDBC Oracle drivers and JDK 1.3.1 with connection pooling? Im using Oracle 8.1.7s JDBC driver (classes12) with JDK 1.3.0. And it seems to have some problems to handle CLOB. But there has not been any problem except CLOB problem up to now. I heard from Oracle technical support that Oracle doesnt support JDK1.3.x officially. -HK -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, KevinSent: Friday, July 27, 2001 6:30 AMTo: Orion-InterestSubject: Anyone experience any problems with JDBC Oracle drivers and JDK 1.3.1 with connection pooling? I have been trying to figure out why I can't connect to our Oracle database. We are running JDK 1.3.1 with Orion 1.5.2. We are using the jdbc.zip (I assume classes12.zip). I am reading on Oracle that Oracle 8.1.7 (and 8.1.5) only have JDBC drivers that support JDK 1.2.x. Does this mean running JDK 1.3.1 is a BAD move when using JDBC drivers from Oracle? Should I go back to JDK 1.2.2 for Orion? There are problems with JDK 1.2.2, such as the NT-LOGOFF and what not when running Orion as a service that I am trying to avoid. Please advise me if running Orion with JDK 1.3.1 (on Win2K Server or Solaris) is OK while using Oracle 8.1.5 and/or Oracle 8.1.7 databases and jdbc drivers. Thanks.
RE: Does Orion root .jar files interfere with my web-app WEB-INF/libjar files?
Kit, This is true. Just swap out the orion/xerces.jar and orion/xalan.jar with the versions you want to use. It won't have any side affects on the server. -Jon -Original Message- From: elephantwalker [mailto:[EMAIL PROTECTED]] Sent: Sunday, July 15, 2001 2:03 PM To: Orion-Interest Subject: RE: Does Orion root .jar files interfere with my web-app WEB-INF/libjar files? Kit, post 1.4.8, I don't think xerces is used by Orion, but crimson. So the current release, 1.5.2 uses crimson. Xerces is used by Xalan in the current release. So you can replace the Xerces.jar and Xalan.jar with whatever versions support the version you want. If you don't use xsl transformation, you do not need xerces.jar or xalan.jar. regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Kit Cragin Sent: Sunday, July 15, 2001 1:16 PM To: Orion-Interest Subject: RE: Does Orion root .jar files interfere with my web-app WEB-INF/libjar files? So is there an easy way to reverse or specify the order? xerces et.al. have a different release schedule and may or may not be picked up by Orion. I would rather it be under my control. - Kit -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Hani Suleiman Sent: Sunday, July 15, 2001 2:39 AM To: Orion-Interest Subject: Re: Does Orion root .jar files interfere with my web-app WEB-INF/libjar files? Order of loading is: Entries explicitly in the root classloader (specified by Class-Path in orion.jar's MANIFEST.MF), which is most of what is in the orion/ directory. Next is orion/lib Next is application specific classes, and I think WEB-INF/lib has precedence over WEB-INF/classes Hani On Sun, 15 Jul 2001, Kevin Duffey wrote: Hey all, I am wondering..Orion comes with xerces, parser, jaxp and so on in the root dir. If I put the latest xerces (1.4.1) into my web-inf/lib dir, put the soap.jar in there, put parser.jar in there, jaxp.jar, etc..will Orion load my web-inf/lib versions, the root-dir versions, or both..and in what order? Should I remove the xerces.jar from orion root, or copy the latest over the top of the root dir version? Probably stupid questions, but I have read alot on the soap list about people using the wrong version of the xerces.jar, putting it in a certain order in the classpath, etc. I'd like to make sure I am aware of how the .jar files in Orion interfere or load in what order compared to anything duplicated in any web application or enterprise application. Thanks.
RE: Code on entity bean being looked up from a session bean and transaction rollback
Be vary careful if you are going to use sql to modify entity beans that are in memory! You have to perform those sql changes to the entity object outside of any transaction involving said entity AND you must have an orion-ejb-jar.xml file deployed that specifies in the entity-deployment that the server does not have exclusive write access (exclusive-write-access=false) to the DB. Something like this: entity-deployment name=ejb/Address location=ejb/Address wrapper=AddressHome_EntityHomeWrapper12 exclusive-write-access=false validity-timeout=30 max-tx-retries=3 table=order_addresses isolation=committed data-source=jdbc/OrderServiceEJB Otherwise when you shut down the server ejbStore() will be called and the entity in memory will overwrite any changes made to the DB directly. -Jon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Sunday, July 15, 2001 8:50 PM To: Orion-Interest Subject: Code on entity bean being looked up from a session bean and transaction rollback Hi everyone, I have a problem with a sequence like this Stateless session bean (bit of sql in a function f1) and calls an entity bean. When the entity bean fails the changes done by sql are not rolled back. (But if sql fails the entity bean changes are rolled back). So I tried another method suggested i.e. the sql was replcaed by entity bean entity1 which was going to call entity22. Suppose entity1 calls entity2 and entity2 fails, then there is a rollback(for both), but when I shut down the server all the changes which were supposed to be rolled back are undone! And another case when something in entity1 fails, the entity2 changes are not rolled back and it looks like I am still back to square one. Any idea if this is an orion bug or something? i would really love to get down to the root of this problem. If I start writing sql code in my session beans instead of using entity beans. Everything works out perfectly well. But I still think that this is not a solution. I still feel that even if I have my sql in the method of one statelesss session bean and one entity update all should be able to work. After all, the same code works in J2EE. I might probably be missing something. Hs anyone got a simple example on having a mix of sql and entity updates in one method of a statelss(or stateful) bean which can do a rollback it the entity fails. Thanks in advance. Kind Regards Aby
RE: Transaction problems
As far as I have seen Orion behaves as per spec in regard to transactions. I am not sure what the default transaction type Orion will assume if you do not explicitly declare one in the ejb-jar.xml file but I imagine it defaults to supports. You should explicitly declare your transaction attribute to required in order to ensure that the session beans join the transaction of the entity beans. Like so: container-transaction method ejb-nameLogEntEJB/ejb-name method-name*/method-name trans-attributeRequired/trans-attribute /method method ejb-nameEntUtenteEJB/ejb-name method-name*/method-name trans-attributeRequired/trans-attribute /method /container-transaction Cheers, -Jon -Original Message- From: Christian Bagnoli [mailto:[EMAIL PROTECTED]] Sent: Friday, July 13, 2001 5:00 AM To: Orion-Interest Subject: Transaction problems Hi, we're implementing an entity bean with transactional (container managed) methods. This bean is accessed by a session statefull bean. We have transactional problem when a method fails (that is throws an EJBException) because orion doesn't rollback the transaction. Does anybody figure out how to make orion rollback the transaction? We have also tried with a session stateless/stateful having the same problem . Also implementing the SessionSycronization interface doesn't trap the transaction boundaries. Our data-source.xml is: data-source class=com.evermind.sql.DriverManagerDataSource name=SetmoveDS location=jdbc/SetmoveDS xa-location=jdbc/xa/MySetmoveDS ejb-location=jdbc/myEJBDS connection-driver=oracle.jdbc.OracleDriver username=test password=test url=jdbc:oracle:thin:test/test@testsun:1521:test inactivity-timeout=30 / we use orion 1.5.2. the ejb-jar.xml is: . session display-nameLogEntJAR/display-name descriptionLogEntJAR/description ejb-nameMyLogEnt/ejb-name homesetmove.beans.logica.LogEntHome/home remotesetmove.beans.logica.LogEnt/remote ejb-classsetmove.beans.logica.LogEntEJB/ejb-class session-typeStateful/session-type transaction-typeContainer/transaction-type ejb-ref ejb-ref-nameMyEntUtente/ejb-ref-name ejb-ref-typeEntity/ejb-ref-type homesetmove.beans.logica.EntUtenteHome/home remotesetmove.beans.logica.EntUtente/remote /ejb-ref /session . entity display-nameEntUtenteJAR/display-name descriptionEntUtenteJAR/description ejb-nameMyEntUtente/ejb-name homesetmove.beans.logica.EntUtenteHome/home remotesetmove.beans.logica.EntUtente/remote ejb-classsetmove.beans.logica.EntUtenteEJB/ejb-class persistence-typeBean/persistence-type prim-key-classjava.lang.String/prim-key-class reentrantfalse/reentrant resource-ref descriptiondescription/description res-ref-namejdbc/SetmoveDS/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth /resource-ref /entity . container-transaction method ejb-nameLogEntEJB/ejb-name method-name*/method-name /method method ejb-nameEntUtenteEJB/ejb-name method-name*/method-name /method /container-transaction thanks a lot. Christian
