RE: [OJB-developers] Select count(x)

[Charles A. <cha...@hp...>]

Hello,

> There will be no problems if different threads are using different
> RowReaders for the same class.
> But: there my be problems if to threads are manipulating a 
> ClassDescriptor
> simultaneously.
> thread 1 says: use RowReaderDefaultImpl,
> thread 2 says: use PagingRowReader 
> thread 1 acquires a ResultSetIterator an will be using a 
> PagingRowreader
> although it asked for a default RowReader.
> 
> You'll have to implement some additional access management to 
> avoid such
> errors.

Looking at the code, as I understand it - and please correct me if I'm
wrong, you could also get this situation
thread 1 says : do a query on sample.class, and (by default) uses a
RowReaderDefaultImpl
thread 1 says : start to iterate on the results
thread 2 says : set sample.class rowreader to PagingRowReader, and do a
query
thread 2 says : start to iterate on the results
thread 1 says : get me another object.

I think at this point, thread 1 will get the object using the PaginRowReader
- not the RowReadeDefaultImpl. The reason I think this, is this line in the
RsIterator.getObjectFromResultSet method : 

	Object result = m_mif.getRowReader().readObjectFrom(m_rs, m_mif);

The result of which is that on each Iterator.next() execution, the RowReader
is got from the ClassDescriptor.

And that could be problematic. As I say, I could be wrong, and if so, please
accept my apologies.
 
> A general remark:
> I'm not quite sure what you want to to with your paging component.
> My concept of a paging display is as follows.

[...]

Ah. My requirement is a little more sophisticated than that. 
I need to be able to present the user with a search form, to build up the
query criteria.

When the user hits 'search', I need to be able to get the first 'page' of -
say 10 objects.
I also need to display a list of page numbers, to enable the user to jump to
a specified page.

This will be in a web application; I do not want to keep the ResultSet open
over more than one HTTP request.

It will also be a common requirement in many different searches, which is
why it needs to be a generic component.

I have attached a jar file containing my source code so far, containing the
following classes :
domain.DebtorMaster: 	a simple domain class for searching.
pager.PagingReader 	a simple rowreader that has a flag that can prevent
objects 					from being materialized.
pager.QueryCount 	 	an interface for getting the number of
results from a query.
pager.QueryCountImpl 	an implementation of the above.
pager.QueryPager 		provides a way of getting the number of
pages in a query, and 					retrieving a
specified page. This is quite well javadoc-ed.
test.Main			ignore this : just an experimentation class
that I meant to take out 				of the jar and
forgot to.
test.TestQueryCount	a test of the QueryCountImpl object.
test.TestQueryPager	an example (and test) of using the pager.

This is work-in-progress. The result objects are not registered to a
transaction. I have commented out the use of the PagingReader, due to the
NullPointerException being thrown as I mentioned in my last email (as well
as my threading concerns).

Finally, I attach a screen dump of a test screen of this component in our
application  : hopefully it will make it all a little clearer. (Note that
the search criteria are currently ignored; indeed, the search criteria don't
even apply to the results displayed ! also, the PageNo and PageSize fields
are just for debugging).

I hope this is of some use to someone, and I would be happy for any of this
code to be incorporated into OJB (if it is useful).

Best Wishes,

Charles.

P.S. I hope people don't mind binaries being sent to this list; they're not
very big. If you do mind, please accept my apologies.



This email and any attachments are strictly confidential and are intended
solely for the addressee. If you are not the intended recipient you must
not disclose, forward, copy or take any action in reliance on this message
or its attachments. If you have received this email in error please notify
the sender as soon as possible and delete it from your computer systems.
Any views or opinions presented are solely those of the author and do not
necessarily reflect those of HPD Software Limited or its affiliates.

 At present the integrity of email across the internet cannot be guaranteed
and messages sent via this medium are potentially at risk.  All liability
is excluded to the extent permitted by law for any claims arising as a re-
sult of the use of this medium to transmit information by or to 
HPD Software Limited or its affiliates.