Gary Richards wrote:
Hi,
It's almost certain (at least for me with JBoss) the eager-release. I turned it off and everything i expected came back through the query.
That's what I expected. I had a closer look at the code. OJB uses a class StatementManager to handle jdbc statement resources. the method StatementManager.closeResources(Statement stmt, ResultSet rs) is meant to close a statement after use.
it contains the following lines:
/*
*********************************************
special stuff for OJB within JBoss
********************************************
*/
if (m_eagerRelease)
{
m_conMan.releaseConnection();
}clsoing the underlying connection will avoid the JBOSS "Successfully closed a connection for you" messages.
But it is problematic because a PersistenceBroker uses only one connection. once the connection is released other operations executed by the same broker instance will fail!
The only safe point to release a connection is in the broker commit() or abort() methods! This looks like a design issue.
But I am not sure as I did not add this feature. I hope Armin can spread some more light on this...
For the time being I think the only safe option is to set eager-release to false.
We than have to have a closer look at the ODMG insert problem you have.
Do you see any OJB related exceptions in the stacktrace? Or only those org.jboss.resource.connectionmanager.* exceptions? (They look like warnings to me and should not do any harm?!)
cheers, Thomas
Did get a few stack traces of the sort [CachedConnectionManager] Successfully closed a connection for you. Please close them yourself: [EMAIL PROTECTED]
at org.jboss.resource.connectionmanager.CachedConnectionManager.closeAll(CachedConnectionManager.java:376) at org.jboss.resource.connectionmanager.CachedConnectionManager.popMetaAwareObject(CachedConnectionManager.java:199) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:190) at org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSessionInstanceInterceptor.java:271) etc...
I had eager-release on as thats's what it said to do in the deployment docs for JBoss 3.0 and greater. Unfortuanately inserts don't seem to work for ODMG when setting eager-release to false. I get a first stack trace,
18:08:22,070 INFO [CachedConnectionManager] Successfully closed a
connection for you. Please close them yourself:
[EMAIL PROTECTED] java.lang.Exception: Stack Trace at
org.jboss.resource.connectionmanager.CachedConnectionManager.closeAll(CachedConnectionManager.java:376)
at
org.jboss.resource.connectionmanager.CachedConnectionManager.popMetaAwareObject(CachedConnectionManager.java:199)
at
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:190)
at
org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSessionInstanceInterceptor.java:271)
followed by a few pages of
18:08:22,070 INFO [CachedConnectionManager] Successfully closed a
connection for you. Please close them yourself:
[EMAIL PROTECTED] java.lang.Exception: Stack Trace at
org.jboss.resource.connectionmanager.CachedConnectionManager.closeAll(CachedConnectionManager.java:376)
at
org.jboss.resource.connectionmanager.CachedConnectionManager.popMetaAwareObject(CachedConnectionManager.java:199)
at
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:190)
at
org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSessionInstanceInterceptor.java:271)
etc...
which is probably why we need eager-release for JBoss. Presumably the eager-release gives OJB a hint to cleanup its connections before JBoss comes to repossess them.
regards
Gary
-----Original Message----- From: Thomas Mahler [mailto:[EMAIL PROTECTED] Sent: 02 June 2003 17:44 To: OJB Users List Subject: Re: Limited collection returned
So both of you use the eager-release="true" feature. Have you tried to disable it?
Maybe Armin knows a bit more about this feature ?
cheers, Thomas
Ken Dempster wrote:
My setup is as follows: Jboss 3.2.1 OBJ 1.0 RC3 OJB.properties set
to PersistenceBrokerImpl, PersistenceBrokerFactoryDefaultImpl, and
ConnectionFactoryManagedImpl, ObjectCachePerBrokerImpl. DB2
database Server AS400 running both Jboss and DB2 I generate my own
JdbcConnectionDescriptor with the following settings: JdbcConnectionDescriptor descriptor = new
JdbcConnectionDescriptor(); descriptor.setBatchMode(false); descriptor.setDatasourceName("java:DB2DS"); descriptor.setDbAlias("serverName"); descriptor.setDbms("Db2"); descriptor.setDefaultConnection(true); descriptor.setEagerRelease(true); descriptor.setIgnoreAutoCommitExceptions(false); descriptor.setJcdAlias("java:DB2DS"); descriptor.setJdbcLevel("2.0"); descriptor.setPassWord("password");
descriptor.setProtocol("jdbc"); descriptor.setSubProtocol("db2"); descriptor.setUseAutoCommit(0); descriptor.setUserName("user_name"); SequenceDescriptor
sequenceDescriptor = new SequenceDescriptor("org.apache.ojb.broker.util.sequence.SequenceManagerN
extValImpl");
- Ken
Ken Dempster Programmer Analyst Vision Solutions, Inc.
17911 Von Karman Ave, 5th Floor Irvine, CA 92614 UNITED STATES
Tel: +1 (949) 253-6500 Fax: +1 (949) 253-6501 Email:
[EMAIL PROTECTED] <http://www.visionsolutions.com/> Disclaimer - 6/2/2003 The contents of this e-mail (and any
attachments) are confidential, may be privileged, and may contain
copyright material of Vision Solutions, Inc. or third parties. You
may only reproduce or distribute the material if you are expressly
authorized by Vision Solutions to do so. If you are not the
intended recipient, any use, disclosure or copying of this e-mail
(and any attachments) is unauthorized. If you have received this
e-mail in error, please immediately delete it and any copies of it
from your system and notify us via e-mail at
[EMAIL PROTECTED] -----Original Message----- From:
McCaffrey, John G. [mailto:[EMAIL PROTECTED] Sent: Monday,
June 02, 2003 8:02 AM To: 'OJB Users List' Subject: RE: Limited
collection returned
Thanks for your investigation Gary. This is exactly what I was suspecting (RSIterator not iterating), now I guess the thing is to figure out how the result set got closed. I am not sure why there
seem to be only a few people having this problem, it seems like
such basic functionality that there would be more of an uproar. It
makes me wonder what the afflicted have in common, and for those
people that can get a collection of dependent objects, how is their
setup different (assuming that there are people that are not having
this problem)
my setup I have the basic OJB.props settings default
PersistenceBrokerImpl, PersistenceBrokerFactoryDefaultImpl, ConnectionManagerImpl, and I am using ConnectionFactoryDBCPImpl
(though I have tried the others and still have the problem).
Windows 2000, db-ojb-1.0.rc3.jar, commons-dbcp.jar I am using WSAD (with datasource) and DB2, and I am using the PB API.
###### Gary, Dan, Jin, Ken, etc what is your basic setup?
Is there anybody with this same setup that is able to get a collection of dependent objects? (help me figure out what i have that is different) ###### I feel like a solution is right around the corner. (and its a good thing, because I am supposed to go to production by the end of the week!)
Thanks to Gary and everyone that is looking into this. -john
-----Original Message----- From: Gary Richards [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2003 9:05 AM To: OJB Users List Subject: RE: Limited collection returned
Hi everyone,
Thought I'd offer my current observations on this as I work with Dan and am running off the same codebase (JBoss 3.2.x, MySql, ODMG etc....) and therefore trying to crack the same problem.
I've been using the eclipse debugger to step through the action of invoking a query. I have spent most of the recent time observing private ManageableCollection getCollectionByQuery(Class
collectionClass, Class itemClass, Query query) of the
PersistanceBrokerImpl class (line 1293), inparticular the actions
of the while loop on line 1335 which reads as,
while (((endAt == Query.NO_END_AT_INDEX) || (retrievedCount < numberOfObjectsToFetch)) && iter.hasNext())
I have witnessed the hasNext() call of this condition to return false during the second cycle of the loop, even though I now there to be 13 rows in the database table and 13 elements behind the Iterator. I have determined this (for those who know eclipse) by editing the detail formatter of the RSIterator class to read "this.size()" which shows 13 when I highlight it.
This leads me onto RSIterator.hasNext() (line 216) which I have moved onto observe as a result. I noticed that on the second cycle of the iterator, the call from within hasNext() will issue
hasNext = m_rsAndStmt.m_rs.next(); (line 223)
This throws an expection which is caught by the same method so that false is returned.
catch (Exception ex) { hasNext = false; }
I have noticed that the message given by this exception ex (which is not logged, only gets caught) is "Operation not allowed after ResultSet closed". This certainly suggests that something has closed the ResultSet before the iterator has been fininshed with (exactly what it says in the message ;) ).
This almost always seems to happen after dependant objects have been retieved as when we set auto-retrieve = "false" in repository_user.xml for the appropriate property we get all rows of the single table we query on but no dependant objects, however when we set auto-retrieve = "true" we get only the first row of the single table and all its dependant objects.
Is this possibly linked to the eager-release feature which needs to be enabled for operation on JBoss, or a side effect of bug OJB172?
Any other thoughts?
regards
Gary
-----Original Message----- From: Dan Hanley Sent: Mon 02/06/2003
14:38 To: OJB Users List Cc: Subject: RE: Limited collection
returned
Jin Are you also running in a managed environment (e.g. jBoss)? I
suspect the bug you're referring to is: Type : Defect Issue
Id : OJB172 Reported by: Rob Kischuk rkischuk - (rkischuk <at>
gttx.org) Details: Platform: PC Operating system: windows 2000 Summary: Loading composite object leads to truncated collection Description: Repeated calls to retrieve a collection of objects that each contain another object are retrieving truncated results,
which are incrementally built to their proper length using repeated
requests. Status: New Priority: Undecided Severity: Major Functional area: Setup ... which sounds like it could be the
culprit. A colleague of mine is trying to trace through with the
eclipse debugger to see if we can cast any light on this. You are
not alone, its holding a lot of people up... Dan -----Original
Message----- From: Jin Bal [mailto:[EMAIL PROTECTED] Sent: Fri
30/05/2003 22:07 To: OJB Users List Cc: Subject: Re: Limited
collection returned I'm also having this problem - thank god
someone else's said so ! it's been driving me mad ;-) i've been
using ojb since 0.9.5 and have only noticed it recently. (sorry can't be more precise than that) here's the offending class
descriptor <class-descriptor class="com.buyacar.businessobjects.Vehicle" table="vehicle"> ....blah blah properties etc <!-- IMAGES --> <collection-descriptor name="images" auto-retrieve="true" element-class-ref="com.buyacar.businessobjects.VehicleImage"> <inverse-foreignkey field-id-ref="1"/> </collection-descriptor> </class-descriptor> <class-descriptor class="com.buyacar.businessobjects.BACVehicleDetails" table="bac_details"> <reference-descriptor name="vehicle" class-ref="com.buyacar.businessobjects.Vehicle" auto-retrieve="true"> <foreignkey field-id-ref="2"/> </reference-descriptor> </class-descriptor> whenever I load a
BACVehicleDetails (and therefore a Vehicle) I only ever get one
image in the collection. more over I have a search engine that
only returns 1 result the first time then 2 on the second submit
then 3 ......etc :-( heres the search engine code PersistenceBroker broker = null; try { broker = getBroker(); Criteria criteria = new Criteria(); // check if theyve specified a
price bracket if(searchParams.getMaxPrice() !=null && searchParams.getMinPrice()!=null) { criteria.addBetween("price",searchParams.getMinPrice(),searchParams.getM
axPr ice()); } else if(searchParams.getMaxPrice()!=null && searchParams.getMinPrice()==null) { criteria.addLessOrEqualThan("price",searchParams.getMaxPrice()); }
else if(searchParams.getMaxPrice()==null && searchParams.getMinPrice()!=null) { criteria.addGreaterOrEqualThan("price",searchParams.getMinPrice());
} if(searchParams.getManufacturer() !=null && searchParams.getModel()==null) { criteria.addEqualTo("vehicle.model.manufacturerId",searchParams.getManuf
actu rer()); } if(searchParams.getModel() !=null) { criteria.addEqualTo("vehicle.modelId",searchParams.getModel()); } if(searchParams.getBodyStyle() != null) { criteria.addEqualTo("vehicle.derivative.bodyStyleId",searchParams.getBod
ySty le()); } if(searchParams.getFuelType() != null) { criteria.addEqualTo("vehicle.derivative.fuelId",searchParams.getFuelType
()); } if(searchParams.getOrderBy() !=null) { criteria.addOrderByAscending(searchParams.getOrderBy()); } if(searchParams.getChannel()!=null && !searchParams.getChannel().equals("")) { criteria.addEqualTo("channel",searchParams.getChannel()); } criteria.addEqualTo("status",searchParams.getStatus()); criteria.addEqualTo("visibility",searchParams.getVisibility()); criteria.addGreaterOrEqualThan("displayTo",new java.util.Date()); criteria.addLessOrEqualThan("displayFrom",new java.util.Date()); Query query = new QueryByCriteria(BACVehicleDetails.class,criteria,true); Collection
c = broker.getCollectionByQuery(query); logger.debug("collection
size: "+c.size()); Iterator results = c.iterator(); ArrayList list
= new ArrayList(); while(results.hasNext()) { // perform cast now
to check that we've got the correct object type BACVehicleDetails
vDetails = (BACVehicleDetails) results.next(); list.add(vDetails); } return list; } finally { if (broker!=null) { broker.close(); } }
sorry for the long code post it seems that when the cache is
filled up it works ok help this is stopping me going live with the
site :-( BTW I did a search on the dev list and noticed a bug opened on the 23rd MAy but i can't find it now cheers Jin -----
Original Message ----- From: "McCaffrey, John G."
<[EMAIL PROTECTED]> To: "'OJB Users List'"
<[EMAIL PROTECTED]> Sent: Friday, May 30, 2003 5:52 PM Subject: RE: Limited collection returned > yes, I also noticed
that, and I tried pre-fetching, but that didn't help me > either. >
> so are you having the same problem then? You are only getting
one row back, > instead of many? > > (my collection is filled
properly with the right child elements, but I am > not getting all
of the parents that match the query, and the query is select > all
parents) > > can you see the SQL? I couldn't get P6Spy to work, so I don't know what the > sql looks like. > > thanks for speaking up,
I wonder if anyone else has had/is having this > problem! > > -John
> > -----Original Message----- > From: Dan Hanley
[mailto:[EMAIL PROTECTED] > Sent: Friday, May 30, 2003 11:47 AM >
To: OJB Users List > Subject: RE: Limited collection returned > > >
John > Setting auto-retrieve = "false" works for me using JBoss &
mySQL *except* > that then I don't get any dependant ojbects loaded
:-( > > > -----Original Message----- > From: McCaffrey, John G. [mailto:[EMAIL PROTECTED] > Sent: 30 May 2003 17:45 > To:
'OJB Users List' > Subject: RE: Limited collection returned > > > I
have been having the same problem. It seems like the initial query > actually gets all the rows, but the RSIterator only gives you one
at a time. > In my situation if I have 4 rows that match the query, and I execute the > query once, I only get one row, each
additional time I execute the query I > get one more row (all
previous rows are also returned in the collection). > This is only
happening for a referenced collection, all of my other queries >
are working fine. I have no Idea what the deal is, I really hope
that > someone can help you. > > -John > > -----Original
Message----- > From: Ken Dempster [mailto:[EMAIL PROTECTED] > Sent: Friday, May 30, 2003
11:38 AM > To: [EMAIL PROTECTED] > Subject: Limited collection
returned > > > Most everything works except I only get one out of
the know four row > objects from the table in my collection. I
want to get all the row > objects in the table. My question is why
am I only getting only one row > object? I am not sure what I am
doing something wrong. > > Here is how I have things setup. I have
set jboss 3.2 as suggested in > the deployment section of the
documentation and have jboss configured it > with data source to
connect to a DB2 database. I am requesting a > collection from a
client to a SessionBean that delegates to a > PersistenceBroker
instance. Basicly I am using the code in > PersistenceBrokerBean
as a template for my EJB. I do generate my own >
JdbcConnectionDescriptor and pass it to the ConnectionRepository
instead > of using the repository.xml to define my JdbcConnectionDescriptor. > > My query looks as follows: > Query
query = new QueryByCriteria(Runner.class, null); > > Collection
list = > getPersistenceBrokerRemote().getCollectionByQuery(query); > > > My ClassDescriptor of the collection of objects I am trying
to get is > defined in the repository_user.xml as follows : > >
<class-descriptor class="test.ojb.Runner" table="KENLIB.RUNNER"> > > <field-descriptor name="m_id" column="ID" jdbc-type="INTEGER" >
primarykey="true" autoincrement="true"/> > > <field-descriptor
name="m_name" column="NAME" jdbc-type="VARCHAR"/> > >
<collection-descriptor name="m_times" element-class-ref="test.ojb.Time"> > > <inverse-foreignkey
field-ref="m_id"/> > > </collection-descriptor> > >
</class-descriptor> > > <class-descriptor class="test.ojb.Race" table="KENLIB.RACE"> > > <field-descriptor name="m_id" column="ID" jdbc-type="INTEGER" > primarykey="true" autoincrement="true"/> > >
<field-descriptor name="m_location" column="LOCATION" >
jdbc-type="VARCHAR"/> > > <field-descriptor name="m_date"
column="DATE" jdbc-type="DATE"/> > > </class-descriptor> > >
<class-descriptor class="test.ojb.Time" table="KENLIB.RACE_TIME"> >
> <field-descriptor name="m_id" column="ID" jdbc-type="INTEGER" >
primarykey="true" autoincrement="true"/> > > <field-descriptor
name="m_runner_id" column="RUNNER_ID" > jdbc-type="INTEGER"/> > >
<field-descriptor name="m_race_id" column="RACE_ID" >
jdbc-type="INTEGER"/> > > <field-descriptor name="m_time"
column="TIME" jdbc-type="VARCHAR"/> > > <reference-descriptor
name="m_race" class-ref="test.ojb.Race"> > > <foreignkey
field-ref="m_race_id"/> > > </reference-descriptor> > >
</class-descriptor> > > > > > Ken Dempster > Programmer Analyst >
Vision Solutions, Inc. > > 17911 Von Karman Ave, 5th Floor >
Irvine, CA 92614 > UNITED STATES > > Tel: +1 (949) 253-6500 > Fax:
+1 (949) 253-6501 > Email: [EMAIL PROTECTED] >
<http://www.visionsolutions.com/> > Disclaimer - 5/30/2003 > The
contents of this e-mail (and any attachments) are confidential, may
be > privileged, and may contain copyright material of Vision
Solutions, Inc. or > third parties. You may only reproduce or
distribute the material if you are > expressly authorized by Vision
Solutions to do so. If you are not the > intended recipient, any
use, disclosure or copying of this e-mail (and any > attachments)
is unauthorized. If you have received this e-mail in error, >
please immediately delete it and any copies of it from your system
and > notify us via e-mail at [EMAIL PROTECTED] > > > ---------------------------------------------------------------------
> 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] > > ---------------------------------------------------------------------
> 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]
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- 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]
