Trace is working now. May be i have i start of explanation. I saw that 1:n relations are all read ( checked ) , even if no getter (getCollections) exists on mapped object. That's because my process is running slower i think.
I don't known why this occurs. I guess you're going to tell me that i have to check all my auto-retrieve !! ... On 2/6/06, Bruno CROS <[EMAIL PROTECTED]> wrote: > > > 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] > > > > >
