You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Ba...@Koopmanint.com on 2008/01/17 11:52:08 UTC
[Trinidad] Pagination in a ?
Hi List,
It's fairly easy to implement pagination with a <tr:table> component. Just
set the "rows" and "first" attributes and you're done. But it turns out
that the pagination is not implemented very smart. Let me explain my
case...
I have a database with some very large tables (10000 to 100000 records per
table). The database is (sadly enough) not too fast. So to make the user
interface responsive to the users, it is very important that only the data
that is displayed is fetched from the database. Therefore, I implemented a
"lazy list", as suggested on http://www.ilikespam.com/blog/lazy_list. I
expected to get much better performance, but this did not happen. I added
some logging to the lazy list to see what's happening. It turns out that
the table is prefetching a lot more rows that the ones that are displayed
initially.
I did set the "rows" attribute to 10, but it seems the table is fetching
about 300 rows at a time. (This takes more than a minute due to my poor
performing database...) This can actually be a nice feature, since the
user can browse very fast through the next 300 records... once they are
loaded. The problem is, however, that the table does not get rendered
until the fetching of those 300 records is finished.
So my question is: is there a way to configure the fetching strategy of
the table component? Is it possible to give rendering a higher priority
than prefetching, for instance? Or can I configure how many rows are
prefetched?
Thanks in advance for your help!
Best regards,
Bart Kummel
AW: [Trinidad] Pagination in a ?
Posted by Döring Markus <Ma...@tcc-products.de>.
I have a solution with my own implementation for Trinidad CollectionModel with
public boolean isRowAvailable() {
if (currentRowIndex > getRowCount()) {
return false;
}
return true;
}
and
public int getRowCount() {
if (size == null) {
size = executeCountQuery();
}
return size.intValue();
}
And it works fast.
Markus Döring
TCC Products GmbH
Von: Renzo Tomaselli [mailto:renzo.tomaselli@tecnotp.it]
Gesendet: Donnerstag, 17. Januar 2008 12:16
An: MyFaces Discussion
Betreff: Re: [Trinidad] Pagination in a <tr:table>?
Bart, I noticed this behavior as well, but I was unable to collect any reply from this list.
The basic issue is that the page navigator calls isRowAvailable() in the data model many times just to setup a predefined number of ranges in the widget, where the user can select from. These calls in turn endup in probing the database with searches, and here performance drops down.
This behavior occurs if you declare in advance the overall dataset size.
If this is undefined (-1), then the widget contains one range plus "more ...".
I found that the second solution avoids a lot of isRowAvailable() calls.
And you cannot be lazy in answering this call: if your model answers yes, while returnin null at the getRowData(), you end up with a blank row.
In any case a significat performance gain is achieve by caching a page, saving/restoring it across requests. Then reload the cache before rendering, if the underlying model might have changed.
Hope it helps.
-- Renzo
Bart.Kummel@Koopmanint.com wrote:
Hi List,
It's fairly easy to implement pagination with a <tr:table> component. Just set the "rows" and "first" attributes and you're done. But it turns out that the pagination is not implemented very smart. Let me explain my case...
I have a database with some very large tables (10000 to 100000 records per table). The database is (sadly enough) not too fast. So to make the user interface responsive to the users, it is very important that only the data that is displayed is fetched from the database. Therefore, I implemented a "lazy list", as suggested on http://www.ilikespam.com/blog/lazy_list. I expected to get much better performance, but this did not happen. I added some logging to the lazy list to see what's happening. It turns out that the table is prefetching a lot more rows that the ones that are displayed initially.
I did set the "rows" attribute to 10, but it seems the table is fetching about 300 rows at a time. (This takes more than a minute due to my poor performing database...) This can actually be a nice feature, since the user can browse very fast through the next 300 records... once they are loaded. The problem is, however, that the table does not get rendered until the fetching of those 300 records is finished.
So my question is: is there a way to configure the fetching strategy of the table component? Is it possible to give rendering a higher priority than prefetching, for instance? Or can I configure how many rows are prefetched?
Thanks in advance for your help!
Best regards,
Bart Kummel
Re: AW: AW: [Trinidad] Pagination in a ?
Posted by Ba...@Koopmanint.com.
Hi Sven,
I am absolutely sure that Trinidad calls isRowAvailable() on rows that are
not visible! To be more specific: isRowAvailable() is called on all rows
that show up in the combobox where you can choose the range. I can confirm
that isRowAvailable() is not called for rows that are beyond the "more..."
item in the combobox. Perhaps that is what you mean to say?
I looked again at the code example on the wiki. It turns out you are right
about not calling the database more than once, since the page is stored as
a member of DataPage. (I overlooked that the first time. Sorry for that.)
That means the wiki solution should work, even while Trinidad keeps
calling isRowAvailable() on invisible rows. (Which is still wrong in my
opinion...)
So I'll give the Wiki solution a try. I'll let you know the outcome...
Best regards,
Bart Kummel
"Rottstock, Sven" <Sv...@sungard.de> wrote on 17-01-2008
14:58:15:
> By the way - you should set the rows attribute in the table and you
> should keep it synchronize with the pageSize parameter in the
> constructor of PagedListDataModel.
> So Trinidad will call isRowAvailable() only for the visible row
> entries. Trust me - i have it also implemented and it works great ;-)
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Rottstock, Sven [mailto:Sven.Rottstock@sungard.de]
> Gesendet: Donnerstag, 17. Januar 2008 14:50
> An: MyFaces Discussion
> Betreff: AW: AW: [Trinidad] Pagination in a <tr:table>?
>
> No it is. You have an object that represent a subset of fetched
> entries (DataPage). Furthermore the total count of entries is also
> stored in this object. If Trinidad is calling isRowAvailable then
> you gets the total count of entries in your database and compares it
> to your current
> rowIndex:
>
> public boolean isRowAvailable() {
> DataPage<T> page = getPage();
> if (page == null)
> return false;
>
> int rowIndex = getRowIndex();
> if (rowIndex < 0) {
> return false;
> } else if (rowIndex >= page.getDatasetSize()) {
> return false;
> } else {
> return true;
> }
> }
>
> Only getRowData will do any database transactions if a desired
> rowIndex is not in a subset.
>
> Regards,
>
> Sven
>
> ________________________________
>
> Von: Bart.Kummel@Koopmanint.com [mailto:Bart.Kummel@Koopmanint.com]
> Gesendet: Donnerstag, 17. Januar 2008 13:22
> An: MyFaces Discussion
> Cc: MyFaces Discussion
> Betreff: Re: AW: [Trinidad] Pagination in a <tr:table>?
>
>
>
> Hi Sven,
>
> Thanks for your reply. I think the solution on the wiki does not solve
> my problem. As Renzo stated in his reply, the real problem is that the
> Trinidad table is calling isRowAvailable() for rows that are not
> visible. (Perhaps we should file a bug report?) The solution on the wiki
> does go to the database too when isRowAvailable() is called, just like
> Trinidad's own CollectionModel, right? I will try implementing my onw
> CollectionModel, as Markus proposed. (Markus' reply is not included in
> the history below, sorry for that.)
>
> I'll let you all know if I succeed.
>
> Best regards,
> Bart Kummel
>
> "Rottstock, Sven" <Sv...@sungard.de> wrote on 17-01-2008
> 13:08:45:
>
> > Please have a look at:
> > http://wiki.apache.org/myfaces/WorkingWithLargeTables
> >
> > You can also use it with Trinidad.
> >
> > Regards,
> >
> > Sven
> >
> > Von: Renzo Tomaselli [mailto:renzo.tomaselli@tecnotp.it]
> > Gesendet: Donnerstag, 17. Januar 2008 12:16
> > An: MyFaces Discussion
> > Betreff: Re: [Trinidad] Pagination in a <tr:table>?
>
> > Bart, I noticed this behavior as well, but I was unable to collect
> > any reply from this list.
> > The basic issue is that the page navigator calls isRowAvailable() in
> > the data model many times just to setup a predefined number of
> > ranges in the widget, where the user can select from. These calls in
> > turn endup in probing the database with searches, and here
> > performance drops down.
> > This behavior occurs if you declare in advance the overall dataset
> size.
> > If this is undefined (-1), then the widget contains one range plus
> "more ...".
> > I found that the second solution avoids a lot of isRowAvailable()
> calls.
> > And you cannot be lazy in answering this call: if your model answers
> > yes, while returnin null at the getRowData(), you end up with a blank
> row.
> > In any case a significat performance gain is achieve by caching a
> > page, saving/restoring it across requests. Then reload the cache
> > before rendering, if the underlying model might have changed.
> > Hope it helps.
> >
> > -- Renzo
> >
> > Bart.Kummel@Koopmanint.com wrote:
> >
> > Hi List,
> >
> > It's fairly easy to implement pagination with a <tr:table>
> > component. Just set the "rows" and "first" attributes and you're
> > done. But it turns out that the pagination is not implemented very
> > smart. Let me explain my case...
> >
> > I have a database with some very large tables (10000 to 100000
> > records per table). The database is (sadly enough) not too fast. So
> > to make the user interface responsive to the users, it is very
> > important that only the data that is displayed is fetched from the
> > database. Therefore, I implemented a "lazy list", as suggested on
> > http://www.ilikespam.com/blog/lazy_list. I expected to get much
> > better performance, but this did not happen. I added some logging to
> > the lazy list to see what's happening. It turns out that the table
> > is prefetching a lot more rows that the ones that are displayed
> initially.
> >
> > I did set the "rows" attribute to 10, but it seems the table is
> > fetching about 300 rows at a time. (This takes more than a minute
> > due to my poor performing database...) This can actually be a nice
> > feature, since the user can browse very fast through the next 300
> > records... once they are loaded. The problem is, however, that the
> > table does not get rendered until the fetching of those 300 records
> > is finished.
> >
> > So my question is: is there a way to configure the fetching strategy
> > of the table component? Is it possible to give rendering a higher
> > priority than prefetching, for instance? Or can I configure how many
> > rows are prefetched?
> >
> > Thanks in advance for your help!
> > Best regards,
> > Bart Kummel
AW: AW: [Trinidad] Pagination in a ?
Posted by "Rottstock, Sven" <Sv...@sungard.de>.
By the way - you should set the rows attribute in the table and you should keep it synchronize with the pageSize parameter in the constructor of PagedListDataModel.
So Trinidad will call isRowAvailable() only for the visible row entries. Trust me - i have it also implemented and it works great ;-)
-----Ursprüngliche Nachricht-----
Von: Rottstock, Sven [mailto:Sven.Rottstock@sungard.de]
Gesendet: Donnerstag, 17. Januar 2008 14:50
An: MyFaces Discussion
Betreff: AW: AW: [Trinidad] Pagination in a <tr:table>?
No it is. You have an object that represent a subset of fetched entries (DataPage). Furthermore the total count of entries is also stored in this object. If Trinidad is calling isRowAvailable then you gets the total count of entries in your database and compares it to your current
rowIndex:
public boolean isRowAvailable() {
DataPage<T> page = getPage();
if (page == null)
return false;
int rowIndex = getRowIndex();
if (rowIndex < 0) {
return false;
} else if (rowIndex >= page.getDatasetSize()) {
return false;
} else {
return true;
}
}
Only getRowData will do any database transactions if a desired rowIndex is not in a subset.
Regards,
Sven
________________________________
Von: Bart.Kummel@Koopmanint.com [mailto:Bart.Kummel@Koopmanint.com]
Gesendet: Donnerstag, 17. Januar 2008 13:22
An: MyFaces Discussion
Cc: MyFaces Discussion
Betreff: Re: AW: [Trinidad] Pagination in a <tr:table>?
Hi Sven,
Thanks for your reply. I think the solution on the wiki does not solve
my problem. As Renzo stated in his reply, the real problem is that the
Trinidad table is calling isRowAvailable() for rows that are not
visible. (Perhaps we should file a bug report?) The solution on the wiki
does go to the database too when isRowAvailable() is called, just like
Trinidad's own CollectionModel, right? I will try implementing my onw
CollectionModel, as Markus proposed. (Markus' reply is not included in
the history below, sorry for that.)
I'll let you all know if I succeed.
Best regards,
Bart Kummel
"Rottstock, Sven" <Sv...@sungard.de> wrote on 17-01-2008
13:08:45:
> Please have a look at:
> http://wiki.apache.org/myfaces/WorkingWithLargeTables
>
> You can also use it with Trinidad.
>
> Regards,
>
> Sven
>
> Von: Renzo Tomaselli [mailto:renzo.tomaselli@tecnotp.it]
> Gesendet: Donnerstag, 17. Januar 2008 12:16
> An: MyFaces Discussion
> Betreff: Re: [Trinidad] Pagination in a <tr:table>?
> Bart, I noticed this behavior as well, but I was unable to collect
> any reply from this list.
> The basic issue is that the page navigator calls isRowAvailable() in
> the data model many times just to setup a predefined number of
> ranges in the widget, where the user can select from. These calls in
> turn endup in probing the database with searches, and here
> performance drops down.
> This behavior occurs if you declare in advance the overall dataset
size.
> If this is undefined (-1), then the widget contains one range plus
"more ...".
> I found that the second solution avoids a lot of isRowAvailable()
calls.
> And you cannot be lazy in answering this call: if your model answers
> yes, while returnin null at the getRowData(), you end up with a blank
row.
> In any case a significat performance gain is achieve by caching a
> page, saving/restoring it across requests. Then reload the cache
> before rendering, if the underlying model might have changed.
> Hope it helps.
>
> -- Renzo
>
> Bart.Kummel@Koopmanint.com wrote:
>
> Hi List,
>
> It's fairly easy to implement pagination with a <tr:table>
> component. Just set the "rows" and "first" attributes and you're
> done. But it turns out that the pagination is not implemented very
> smart. Let me explain my case...
>
> I have a database with some very large tables (10000 to 100000
> records per table). The database is (sadly enough) not too fast. So
> to make the user interface responsive to the users, it is very
> important that only the data that is displayed is fetched from the
> database. Therefore, I implemented a "lazy list", as suggested on
> http://www.ilikespam.com/blog/lazy_list. I expected to get much
> better performance, but this did not happen. I added some logging to
> the lazy list to see what's happening. It turns out that the table
> is prefetching a lot more rows that the ones that are displayed
initially.
>
> I did set the "rows" attribute to 10, but it seems the table is
> fetching about 300 rows at a time. (This takes more than a minute
> due to my poor performing database...) This can actually be a nice
> feature, since the user can browse very fast through the next 300
> records... once they are loaded. The problem is, however, that the
> table does not get rendered until the fetching of those 300 records
> is finished.
>
> So my question is: is there a way to configure the fetching strategy
> of the table component? Is it possible to give rendering a higher
> priority than prefetching, for instance? Or can I configure how many
> rows are prefetched?
>
> Thanks in advance for your help!
> Best regards,
> Bart Kummel
AW: AW: [Trinidad] Pagination in a ?
Posted by "Rottstock, Sven" <Sv...@sungard.de>.
No it is. You have an object that represent a subset of fetched entries
(DataPage). Furthermore the total count of entries is also stored in
this object. If Trinidad is calling isRowAvailable then you gets the
total count of entries in your database and compares it to your current
rowIndex:
public boolean isRowAvailable() {
DataPage<T> page = getPage();
if (page == null)
return false;
int rowIndex = getRowIndex();
if (rowIndex < 0) {
return false;
} else if (rowIndex >= page.getDatasetSize()) {
return false;
} else {
return true;
}
}
Only getRowData will do any database transactions if a desired rowIndex
is not in a subset.
Regards,
Sven
________________________________
Von: Bart.Kummel@Koopmanint.com [mailto:Bart.Kummel@Koopmanint.com]
Gesendet: Donnerstag, 17. Januar 2008 13:22
An: MyFaces Discussion
Cc: MyFaces Discussion
Betreff: Re: AW: [Trinidad] Pagination in a <tr:table>?
Hi Sven,
Thanks for your reply. I think the solution on the wiki does not solve
my problem. As Renzo stated in his reply, the real problem is that the
Trinidad table is calling isRowAvailable() for rows that are not
visible. (Perhaps we should file a bug report?) The solution on the wiki
does go to the database too when isRowAvailable() is called, just like
Trinidad's own CollectionModel, right? I will try implementing my onw
CollectionModel, as Markus proposed. (Markus' reply is not included in
the history below, sorry for that.)
I'll let you all know if I succeed.
Best regards,
Bart Kummel
"Rottstock, Sven" <Sv...@sungard.de> wrote on 17-01-2008
13:08:45:
> Please have a look at:
> http://wiki.apache.org/myfaces/WorkingWithLargeTables
>
> You can also use it with Trinidad.
>
> Regards,
>
> Sven
>
> Von: Renzo Tomaselli [mailto:renzo.tomaselli@tecnotp.it]
> Gesendet: Donnerstag, 17. Januar 2008 12:16
> An: MyFaces Discussion
> Betreff: Re: [Trinidad] Pagination in a <tr:table>?
> Bart, I noticed this behavior as well, but I was unable to collect
> any reply from this list.
> The basic issue is that the page navigator calls isRowAvailable() in
> the data model many times just to setup a predefined number of
> ranges in the widget, where the user can select from. These calls in
> turn endup in probing the database with searches, and here
> performance drops down.
> This behavior occurs if you declare in advance the overall dataset
size.
> If this is undefined (-1), then the widget contains one range plus
"more ...".
> I found that the second solution avoids a lot of isRowAvailable()
calls.
> And you cannot be lazy in answering this call: if your model answers
> yes, while returnin null at the getRowData(), you end up with a blank
row.
> In any case a significat performance gain is achieve by caching a
> page, saving/restoring it across requests. Then reload the cache
> before rendering, if the underlying model might have changed.
> Hope it helps.
>
> -- Renzo
>
> Bart.Kummel@Koopmanint.com wrote:
>
> Hi List,
>
> It's fairly easy to implement pagination with a <tr:table>
> component. Just set the "rows" and "first" attributes and you're
> done. But it turns out that the pagination is not implemented very
> smart. Let me explain my case...
>
> I have a database with some very large tables (10000 to 100000
> records per table). The database is (sadly enough) not too fast. So
> to make the user interface responsive to the users, it is very
> important that only the data that is displayed is fetched from the
> database. Therefore, I implemented a "lazy list", as suggested on
> http://www.ilikespam.com/blog/lazy_list. I expected to get much
> better performance, but this did not happen. I added some logging to
> the lazy list to see what's happening. It turns out that the table
> is prefetching a lot more rows that the ones that are displayed
initially.
>
> I did set the "rows" attribute to 10, but it seems the table is
> fetching about 300 rows at a time. (This takes more than a minute
> due to my poor performing database...) This can actually be a nice
> feature, since the user can browse very fast through the next 300
> records... once they are loaded. The problem is, however, that the
> table does not get rendered until the fetching of those 300 records
> is finished.
>
> So my question is: is there a way to configure the fetching strategy
> of the table component? Is it possible to give rendering a higher
> priority than prefetching, for instance? Or can I configure how many
> rows are prefetched?
>
> Thanks in advance for your help!
> Best regards,
> Bart Kummel
Re: AW: [Trinidad] Pagination in a ?
Posted by Ba...@Koopmanint.com.
Hi Sven,
Thanks for your reply. I think the solution on the wiki does not solve my
problem. As Renzo stated in his reply, the real problem is that the
Trinidad table is calling isRowAvailable() for rows that are not visible.
(Perhaps we should file a bug report?) The solution on the wiki does go to
the database too when isRowAvailable() is called, just like Trinidad's own
CollectionModel, right? I will try implementing my onw CollectionModel, as
Markus proposed. (Markus' reply is not included in the history below,
sorry for that.)
I'll let you all know if I succeed.
Best regards,
Bart Kummel
"Rottstock, Sven" <Sv...@sungard.de> wrote on 17-01-2008
13:08:45:
> Please have a look at:
> http://wiki.apache.org/myfaces/WorkingWithLargeTables
>
> You can also use it with Trinidad.
>
> Regards,
>
> Sven
>
> Von: Renzo Tomaselli [mailto:renzo.tomaselli@tecnotp.it]
> Gesendet: Donnerstag, 17. Januar 2008 12:16
> An: MyFaces Discussion
> Betreff: Re: [Trinidad] Pagination in a <tr:table>?
> Bart, I noticed this behavior as well, but I was unable to collect
> any reply from this list.
> The basic issue is that the page navigator calls isRowAvailable() in
> the data model many times just to setup a predefined number of
> ranges in the widget, where the user can select from. These calls in
> turn endup in probing the database with searches, and here
> performance drops down.
> This behavior occurs if you declare in advance the overall dataset size.
> If this is undefined (-1), then the widget contains one range plus "more
...".
> I found that the second solution avoids a lot of isRowAvailable() calls.
> And you cannot be lazy in answering this call: if your model answers
> yes, while returnin null at the getRowData(), you end up with a blank
row.
> In any case a significat performance gain is achieve by caching a
> page, saving/restoring it across requests. Then reload the cache
> before rendering, if the underlying model might have changed.
> Hope it helps.
>
> -- Renzo
>
> Bart.Kummel@Koopmanint.com wrote:
>
> Hi List,
>
> It's fairly easy to implement pagination with a <tr:table>
> component. Just set the "rows" and "first" attributes and you're
> done. But it turns out that the pagination is not implemented very
> smart. Let me explain my case...
>
> I have a database with some very large tables (10000 to 100000
> records per table). The database is (sadly enough) not too fast. So
> to make the user interface responsive to the users, it is very
> important that only the data that is displayed is fetched from the
> database. Therefore, I implemented a "lazy list", as suggested on
> http://www.ilikespam.com/blog/lazy_list. I expected to get much
> better performance, but this did not happen. I added some logging to
> the lazy list to see what's happening. It turns out that the table
> is prefetching a lot more rows that the ones that are displayed
initially.
>
> I did set the "rows" attribute to 10, but it seems the table is
> fetching about 300 rows at a time. (This takes more than a minute
> due to my poor performing database...) This can actually be a nice
> feature, since the user can browse very fast through the next 300
> records... once they are loaded. The problem is, however, that the
> table does not get rendered until the fetching of those 300 records
> is finished.
>
> So my question is: is there a way to configure the fetching strategy
> of the table component? Is it possible to give rendering a higher
> priority than prefetching, for instance? Or can I configure how many
> rows are prefetched?
>
> Thanks in advance for your help!
> Best regards,
> Bart Kummel
AW: [Trinidad] Pagination in a ?
Posted by "Rottstock, Sven" <Sv...@sungard.de>.
Please have a look at:
http://wiki.apache.org/myfaces/WorkingWithLargeTables
You can also use it with Trinidad.
Regards,
Sven
________________________________
Von: Renzo Tomaselli [mailto:renzo.tomaselli@tecnotp.it]
Gesendet: Donnerstag, 17. Januar 2008 12:16
An: MyFaces Discussion
Betreff: Re: [Trinidad] Pagination in a <tr:table>?
Bart, I noticed this behavior as well, but I was unable to collect any
reply from this list.
The basic issue is that the page navigator calls isRowAvailable() in the
data model many times just to setup a predefined number of ranges in the
widget, where the user can select from. These calls in turn endup in
probing the database with searches, and here performance drops down.
This behavior occurs if you declare in advance the overall dataset size.
If this is undefined (-1), then the widget contains one range plus "more
...".
I found that the second solution avoids a lot of isRowAvailable() calls.
And you cannot be lazy in answering this call: if your model answers
yes, while returnin null at the getRowData(), you end up with a blank
row.
In any case a significat performance gain is achieve by caching a page,
saving/restoring it across requests. Then reload the cache before
rendering, if the underlying model might have changed.
Hope it helps.
-- Renzo
Bart.Kummel@Koopmanint.com wrote:
Hi List,
It's fairly easy to implement pagination with a <tr:table>
component. Just set the "rows" and "first" attributes and you're done.
But it turns out that the pagination is not implemented very smart. Let
me explain my case...
I have a database with some very large tables (10000 to 100000
records per table). The database is (sadly enough) not too fast. So to
make the user interface responsive to the users, it is very important
that only the data that is displayed is fetched from the database.
Therefore, I implemented a "lazy list", as suggested on
http://www.ilikespam.com/blog/lazy_list. I expected to get much better
performance, but this did not happen. I added some logging to the lazy
list to see what's happening. It turns out that the table is prefetching
a lot more rows that the ones that are displayed initially.
I did set the "rows" attribute to 10, but it seems the table is
fetching about 300 rows at a time. (This takes more than a minute due to
my poor performing database...) This can actually be a nice feature,
since the user can browse very fast through the next 300 records... once
they are loaded. The problem is, however, that the table does not get
rendered until the fetching of those 300 records is finished.
So my question is: is there a way to configure the fetching
strategy of the table component? Is it possible to give rendering a
higher priority than prefetching, for instance? Or can I configure how
many rows are prefetched?
Thanks in advance for your help!
Best regards,
Bart Kummel
commandButton does invoke action method
Posted by "Zheng, Xiahong" <Xi...@FMR.COM>.
How do I go about debug such problem? I have a PhaseListener installed
and it indicates all six phases have been executed. Without source codes
for 1.2 RI, I am really stuck.