This one time, at band camp, Peter T. Brown said:
PTB>Thanks for the reply. I was hoping you'd just tell me to update from CVS
PTB>or sacrifice a chicken or something...
PTB>
PTB>The code that produces this is a cascade of classes which use castor's
PTB>CALL SQL capability to pull out records from dynamically generated
PTB>tables. The mapping.xml refers to an unused table, but matches the
PTB>format of the dynamically generated tables. The code takes out 220
PTB>objects, passes each to a process() method, and then calls commit. The
PTB>whole process repeats itself n number of times for segments of various
PTB>sizes. Its very curious because because it doesn't happen all the time
PTB>-- only for certain segments. When it does happen, there is an obvious
PTB>and massive memory leek -- the JVM eventually dies completely.
PTB>
PTB>There are quite a few classes abstracting castor specifics out, so its
PTB>difficult for me to show the code all the way back to the JDO object.
PTB>But pasted below is the immediately executing code.
PTB>
PTB>
PTB>Thanks again,
PTB>
PTB>Peter
PTB>
PTB>
PTB> while (!isDone) {
PTB> try {
PTB> if ( !pm.currentTransaction().inTransaction() ) {
PTB> pm.currentTransaction().begin();
PTB> prepare();
PTB> }
PTB> }
PTB> catch ( Exception ex ) {
PTB> ex.printStackTrace();
PTB> }
PTB>
PTB> logger.println("Getting next " + visitorBufferSize +
PTB> " VisitorPointers");
PTB>
PTB> Vector vp = manager.getManyBySQL("ID","0",">",
PTB> "LIMIT " + visitorBufferSize + ", " + lastAt,
PTB> "\"ID\",\"VisitorID\"","VisitorPointer" + cg.getID());
PTB>
PTB> for ( Enumeration e = vp.elements();
PTB> e.hasMoreElements(); ) {
PTB> VisitorPointer vpointer =
PTB> (VisitorPointer) e.nextElement();
PTB>
PTB> process(vpointer.getVisitor());
PTB>
PTB> logger.println("Now processing Visitor: " +
PTB> vpointer.getVisitor().getID());
PTB>
PTB> visitorCount++;
PTB> }
PTB>
PTB> try {
PTB> pm.currentTransaction().commit();
PTB> }
PTB> catch ( Exception ex ) {
PTB> ex.printStackTrace();
PTB> }
PTB>
PTB> lastAt += visitorBufferSize;
PTB> if ( vp.isEmpty() ) {
PTB> isDone = true;
PTB> if ( message == null ) {
PTB> message = "Your visitor's have been successfully " +
PTB> "processed.";
PTB> }
PTB> }
PTB> }
PTB>
PTB>
PTB>On Mon, 2002-10-28 at 15:20, Bruce Snyder wrote:
PTB>> This one time, at band camp, Peter T. Brown said:
PTB>>
PTB>> PTB>Could anyone be so kind as to explain why I get the following error? It
PTB>> PTB>appears to create a memory leak situation although no transaction is
PTB>> PTB>rolled back and all changes get persisted...
PTB>> PTB>
PTB>> PTB>Thank You
PTB>> PTB>
PTB>> PTB>
PTB>> PTB>
PTB>> PTB>java.lang.IllegalStateException: No lock to release!
PTB>> PTB>flywheel.visitor.FastTidbit/1658134 for transaction
PTB>> PTB>org.exolab.castor.jdo.engine.TransactionContextImpl@18bbf6
PTB>> PTB> at org.exolab.castor.persist.LockEngine$TypeInfo.release(Unknown
PTB>> PTB>Source)
PTB>> PTB> at
PTB>> PTB>org.exolab.castor.persist.LockEngine$TypeInfo.access$800(Unknown Source)
PTB>> PTB> at org.exolab.castor.persist.LockEngine.releaseLock(Unknown
PTB>> PTB>Source)
PTB>> PTB> at org.exolab.castor.persist.TransactionContext.commit(Unknown
PTB>> PTB>Source)
PTB>> PTB> at org.exolab.castor.jdo.engine.DatabaseImpl.commit(Unknown
PTB>> PTB>Source)
PTB>> PTB> at
PTB>> PTB>flywheel.persistent.CastorTransaction.commit(CastorTransaction.java:39)
PTB>> PTB> at
PTB>> PTB>flywheel.visitor.VisitorProcessor.run(VisitorProcessor.java:89)
Peter,
In browsing the code of LockEngine$TypeInfo, it's unclear to me why
the lock would not be available to be released. If I were faced with
this situation, I would run my code through a debugger and step through
the flywheel.persistent.CastorTransaction.commit() process by hand to
see what's going on. Unfortunately, I've not seen this before and when
everything is so abstracted, there's little room for any other alternative
(other than dumbing down the code by writing a very straightforward
JUnit test case).
Bruce
--
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
