Well, step by step, i hope that anything will be fine soon. DB Connections are well mounted, thank you very much again.
So, I tested my batch processes and i noted that log4j trace disappeared. I think it's no so hard to resolve (just redirect to my commons logging setup). But the most worrying is that my first process (creation of 400 records qith 400 others each linked) canno't end, crashing in a outofmemory error most of the time. Note that this processes is the simplest i have. According to the notes, i modified auto-update to none. auto-delete were already at none. My repository have been regenerated by xdoclet Ant task. Should i consider new repository description (that i miss) in my described collections (or references)? I known there something wrong. It looks like there exponential reads. But i don't forget that i 'm creating objects from scratch. So, i get rid an infinite read loop. Processes were working without any trouble in 1.0.1. Except the none read 1.N relations during heavy load i related you last week. I'm looking at documentation about well configuring OJB.properties, for little batch processes and multiples objects transaction. My setup is the one who came with ojb_blank. I'm asking me if it's Note that my second connections (in 1.0.1 schema ) just serves me to read only (no update, no creation). so i get rid of a problem of locking with 1.0.4 and a 1.0.1 db core. I guess that my case is not an isolated one. Best regards On 2/4/06, Armin Waibel <[EMAIL PROTECTED]> wrote: > > Hi Bruno, > > Bruno CROS wrote: > > i already have patch torque3.1.1.jar. thanks for advice. I've done since > > start with the build.xml of ojb-blank.jar (so torque). > > > > I have the right database generated now. That's a good point and i thank > you > > all. > > > > On the other hand, i have 2 database connections and it seems they do > not > > work anymore. Of course, i can't see any errors. I d'ont known how to > spy DB > > connections !!? shame, i known. > > > > you can use p6spy > http://db.apache.org/ojb/docu/faq.html#traceProfileSQL > > > > The particularity of one of these connections is that the database has > been > > made with 1.0.1 OJB release. Understand that this database is accessed > by > > my application, and by another one (bigger). So upgrading this DB is not > so > > suitable. > > > > nevertheless, understand too, that my application need to be connected > to > > those two databses, mine in 1.0.4 and the big one in 1.0.1. At the same > time > > of course. > > > > My doubts are about the repository_internal.xml ( describing OJB > tables). If > > these tables are not the same in the 2 DB. How could it work ?? > > > > Seems that the "default" connection doesn't require any of the internal > OJB tables (if you don't use odmg named objects or the specific List/Map > implementations). > > "rushDb" use SequenceManagerHighLowImpl. In this case table OJB_HL_SEQ > is mandatory. The metadata mapping of this object/table changed between > 1.0.1 and 1.0.4 but not the column names (one column was removed between > 1.0.1 and 1.0.4). Thus you could try to use the "old" table with the > 1.0.4 mapping. If this doesn't work you could drop and recreate table > OJB_HL_SEQ (OJB will automatically take care of existing id's and > re-populate the table). > > In "rushDb" you are using useAutoCommit="0". In this case it's mandatory > that the jdbc-driver/DB disable the connection autoCommit property (else > you will run into problems with tx-rollback). > > regards, > Armin > > > > You understand what i mean when you see my repository.xml file. and the > 2 > > next files, parts of it. > > > > ================== > > my repository.xml file > > ===================== > > > > <!ENTITY databaseMathieu SYSTEM "repository_database_mathieu.xml"> > > <!ENTITY databaseRushDb SYSTEM "repository_database_rushDb.xml"> > > <!ENTITY internal SYSTEM "repository_internal.xml"> > > <!ENTITY user SYSTEM "repository_user.xml"> > > <!ENTITY rushDb SYSTEM "repository_rushDb.xml"> > > ]> > > > > > > <descriptor-repository version="1.0" > > isolation-level="read-uncommitted" > > proxy-prefetching-limit="50"> > > > > > > <!-- connection Mathieu --> > > &databaseMathieu; > > <!-- connection rushDB --> > > &databaseRushDb; > > > > <!-- include ojb internal mappings here; comment this if you don't > need > > them --> > > &internal; > > > > <!-- mapping Mathieu --> > > &user; > > > > <!-- mapping RushDb --> > > &rushDb; > > > > > > ================================== > > repository_database_mathieu.xml > > =================================== > > > > <!-- This connection is used as the default one within OJB --> > > <jdbc-connection-descriptor > > jcd-alias="default" > > default-connection="true" > > platform="Oracle9i" > > jdbc-level="2.0" > > driver="oracle.jdbc.driver.OracleDriver" > > protocol="jdbc" > > subprotocol="oracle" > > dbalias="thin:@P615-5:1521:MATHIEU" > > username="xxx" > > password="xxxx" > > batch-mode="false" > > useAutoCommit="1" > > ignoreAutoCommitExceptions="false" > > > > > > > > > > > <!-- > > On initialization of connections the ConnectionFactory change > > the 'autoCommit' > > state dependent of the used 'useAutoCommit' setting. This > > doesn't work in all > > situations/environments, thus for useAutoCommit="1" the > > ConnectionFactory does > > no longer set autoCommit to true on connection creation. > > To use the old behavior (OJB version 1.0.3 or earlier) set > this > > property > > to 'true', then OJB change the autoCommit state (if needed) > of > > new obtained connections at connection initialization to > 'true'. > > If 'false' or this property is removed, OJB don't try to > change > > connection > > autoCommit state at connection initialization. > > --> > > <attribute attribute-name="initializationCheck" > > attribute-value="false" /> > > > > <!-- alternative cache implementations, see docs section > > "Caching" --> > > <object-cache > > class="org.apache.ojb.broker.cache.ObjectCacheTwoLevelImpl"> > > <!-- meaning of attributes, please see docs section > > "Caching" --> > > <!-- common attributes --> > > <attribute attribute-name="cacheExcludes" > attribute-value=""/> > > > > <!-- ObjectCacheTwoLevelImpl attributes --> > > <attribute attribute-name="applicationCache" > > attribute-value="org.apache.ojb.broker.cache.ObjectCacheDefaultImpl"/> > > <attribute attribute-name="copyStrategy" > > attribute-value=" > org.apache.ojb.broker.cache.ObjectCacheTwoLevelImpl$CopyStr > > ategyImpl"/> > > <attribute attribute-name="forceProxies" > > attribute-value="false"/> > > > > <!-- ObjectCacheDefaultImpl attributes --> > > <attribute attribute-name="timeout" attribute-value="900"/> > > <attribute attribute-name="autoSync" attribute-value="true"/> > > <attribute attribute-name="cachingKeyType" > attribute-value="0"/> > > <attribute attribute-name="useSoftReferences" > > attribute-value="true"/> > > </object-cache> > > > > <!-- For more info, see section "Connection Handling" in docs --> > > <connection-pool > > maxActive="30" > > validationQuery="" > > testOnBorrow="true" > > testOnReturn="false" > > whenExhaustedAction="0" > > maxWait="10000"> > > > > <!-- Set fetchSize to 0 to use driver's default. --> > > <attribute attribute-name="fetchSize" attribute-value="0"/> > > > > <!-- Attributes with name prefix "jdbc." are passed directly > to > > the JDBC driver. --> > > <!-- Example setting (used by Oracle driver when Statement > > batching is enabled) --> > > <attribute attribute-name="jdbc.defaultBatchValue" > > attribute-value="5"/> > > > > <!-- Attributes determining if ConnectionFactoryDBCPImpl > > should also pool PreparedStatement. This is > > programmatically disabled > > when using platform=Oracle9i since Oracle statement > caching > > will conflict > > with DBCP ObjectPool-based PreparepdStatement caching > (ie > > setting true > > here has no effect for Oracle9i platform). --> > > <attribute attribute-name="dbcp.poolPreparedStatements" > > attribute-value="false"/> > > <attribute attribute-name="dbcp.maxOpenPreparedStatements" > > attribute-value="10"/> > > <!-- Attribute determining if the Commons DBCP connection > > wrapper will allow > > access to the underlying concrete Connection instance > from > > the JDBC-driver > > (normally this is not allowed, like in J2EE-containers > > using wrappers). --> > > <attribute > > attribute-name="dbcp.accessToUnderlyingConnectionAllowed" > > attribute-value="false"/> > > </connection-pool> > > > > <sequence-manager > > className=" > org.apache.ojb.broker.util.sequence.SequenceManagerNextValImpl"> > > <attribute attribute-name="autoNaming" attribute-value="true"/> > > </sequence-manager> > > > > </jdbc-connection-descriptor> > > > > <!-- Datasource example --> > > <!-- jdbc-connection-descriptor > > jcd-alias="default" > > default-connection="true" > > platform="Hsqldb" > > jdbc-level="2.0" > > jndi-datasource-name="java:DefaultDS" > > username="sa" > > password="" > > batch-mode="false" > > useAutoCommit="0" > > ignoreAutoCommitExceptions="false" > > > > > Add the other elements like object-cache, connection-pool, > > sequence-manager here. > > > > </jdbc-connection-descriptor --> > > > > ============================================== > > repository_database_rushDb.xml > > ============================================== > > > > > > <!-- This connection is used as the default one within OJB --> > > <jdbc-connection-descriptor > > jcd-alias="rushDb" > > default-connection="false" > > platform="MsSQLServer" > > jdbc-level="2.0" > > driver="com.microsoft.jdbc.sqlserver.SQLServerDriver" > > protocol="JDBC" > > subprotocol="microsoft:sqlserver" > > dbalias="//xxx.x.x.x:xxxx" > > username="xxx" > > password="xxxx" > > batch-mode="true" > > useAutoCommit="0" > > ignoreAutoCommitExceptions="true" > > > > > > > <!-- > > On initialization of connections the ConnectionFactory change > > the 'autoCommit' > > state dependent of the used 'useAutoCommit' setting. This > > doesn't work in all > > situations/environments, thus for useAutoCommit="1" the > > ConnectionFactory does > > no longer set autoCommit to true on connection creation. > > To use the old behavior (OJB version 1.0.3 or earlier) set > this > > property > > to 'true', then OJB change the autoCommit state (if needed) > of > > new obtained connections at connection initialization to > 'true'. > > If 'false' or this property is removed, OJB don't try to > change > > connection > > autoCommit state at connection initialization. > > --> > > <attribute attribute-name="initializationCheck" > > attribute-value="false" /> > > > > <!-- alternative cache implementations, see docs section > > "Caching" --> > > <object-cache > > class="org.apache.ojb.broker.cache.ObjectCacheTwoLevelImpl"> > > <!-- meaning of attributes, please see docs section > > "Caching" --> > > <!-- common attributes --> > > <attribute attribute-name="cacheExcludes" > attribute-value=""/> > > > > <!-- ObjectCacheTwoLevelImpl attributes --> > > <attribute attribute-name="applicationCache" > > attribute-value="org.apache.ojb.broker.cache.ObjectCacheDefaultImpl"/> > > <attribute attribute-name="copyStrategy" > > attribute-value=" > org.apache.ojb.broker.cache.ObjectCacheTwoLevelImpl$CopyStr > > ategyImpl"/> > > <attribute attribute-name="forceProxies" > > attribute-value="false"/> > > > > <!-- ObjectCacheDefaultImpl attributes --> > > <attribute attribute-name="timeout" attribute-value="900"/> > > <attribute attribute-name="autoSync" attribute-value="true"/> > > <attribute attribute-name="cachingKeyType" > attribute-value="0"/> > > <attribute attribute-name="useSoftReferences" > > attribute-value="true"/> > > </object-cache> > > > > <!-- For more info, see section "Connection Handling" in docs --> > > <connection-pool > > maxActive="30" > > validationQuery="" > > testOnBorrow="true" > > testOnReturn="false" > > whenExhaustedAction="0" > > maxWait="10000"> > > > > <!-- Set fetchSize to 0 to use driver's default. --> > > <attribute attribute-name="fetchSize" attribute-value="0"/> > > > > <!-- Attributes with name prefix "jdbc." are passed directly > to > > the JDBC driver. --> > > <!-- Example setting (used by Oracle driver when Statement > > batching is enabled) --> > > <attribute attribute-name="jdbc.defaultBatchValue" > > attribute-value="5"/> > > > > <!-- Attributes determining if ConnectionFactoryDBCPImpl > > should also pool PreparedStatement. This is > > programmatically disabled > > when using platform=Oracle9i since Oracle statement > caching > > will conflict > > with DBCP ObjectPool-based PreparepdStatement caching > (ie > > setting true > > here has no effect for Oracle9i platform). --> > > <attribute attribute-name="dbcp.poolPreparedStatements" > > attribute-value="false"/> > > <attribute attribute-name="dbcp.maxOpenPreparedStatements" > > attribute-value="10"/> > > <!-- Attribute determining if the Commons DBCP connection > > wrapper will allow > > access to the underlying concrete Connection instance > from > > the JDBC-driver > > (normally this is not allowed, like in J2EE-containers > > using wrappers). --> > > <attribute > > attribute-name="dbcp.accessToUnderlyingConnectionAllowed" > > attribute-value="false"/> > > </connection-pool> > > > > <!-- alternative sequence manager implementations, see "Sequence > > Manager" guide --> > > <sequence-manager > > className=" > org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl"> > > <!-- attributes supported by SequenceManagerHighLowImpl, > > SequenceManagerInMemoryImpl, SequenceManagerNextValImpl > > please see "Sequence Manager" guide or/and javadoc of class > for > > more information --> > > <attribute attribute-name="seq.start" > attribute-value="200000"/> > > <attribute attribute-name="autoNaming" > attribute-value="true"/> > > > > <!-- attributes supported by SequenceManagerHighLowImpl > > please see "Sequence Manager" guide or/and javadoc of classes > > for more information --> > > <attribute attribute-name="grabSize" attribute-value="20"/> > > > > <!-- optional attributes supported by > SequenceManagerNextValImpl > > (support depends > > on the used database), please see "Sequence Manager" guide > > or/and javadoc of > > classes for more information --> > > <!-- attribute attribute-name="seq.as" > > attribute-value="INTEGER"/ --> > > <!-- attribute attribute-name="seq.incrementBy" > > attribute-value="1"/ --> > > <!-- attribute attribute-name="seq.maxValue" > > attribute-value="999999999999999999999999999"/ --> > > <!-- attribute attribute-name="seq.minValue" > > attribute-value="1"/ --> > > <!-- attribute attribute-name="seq.cycle" > > attribute-value="false"/ --> > > <!-- attribute attribute-name="seq.cache" > > attribute-value="20"/ --> > > <!-- attribute attribute-name="seq.order" > > attribute-value="false"/ --> > > > > </sequence-manager> > > </jdbc-connection-descriptor> > > > > <!-- Datasource example --> > > <!-- jdbc-connection-descriptor > > jcd-alias="default" > > default-connection="true" > > platform="Hsqldb" > > jdbc-level="2.0" > > jndi-datasource-name="java:DefaultDS" > > username="sa" > > password="" > > batch-mode="false" > > useAutoCommit="0" > > ignoreAutoCommitExceptions="false" > > > > > Add the other elements like object-cache, connection-pool, > > sequence-manager here. > > > > </jdbc-connection-descriptor --> > > > > > > > > > > On 2/3/06, Thomas Dudziak <[EMAIL PROTECTED]> wrote: > >> On 2/3/06, Bruno CROS <[EMAIL PROTECTED]> wrote: > >> > >>> i 'm afraid i need to repatch distributed torque-gen-3.1.1.jar > to have > >>> TIMESTAMP jdbc type created for java.sql.Date and > java.sql.timestampas i > >>> wrote in an old old post. (specific to oracle 9i and older ) > >> You might want to try DdlUtils (http://db.apache.org/ddlutils ) instead > >> of Torque, it uses the same schema format and contains an Oracle9 (and > >> an Oracle10 one) platform that can use TIMESTAMP. > >> > >> Tom > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
