Lec wrote: > so what s the most optimized way of doing paging using the IDataProvider?
There is no optimal way. You have to engage your brain and make trade-offs, just like you do with everything else. You can make sure your database is configured to cache the COUNT(*) query, which will be as efficient as you need, I imagine. It will probably also stop you getting stale values, depending how your database vendor handles things. However, even if it caches it, you need to roundtrip to your database to find it, which you may consider sub-optimal. To avoid this, you can cache the result of COUNT(*) in your DAO layer for some time (a few seconds or a minute, say). You then need to decide how to cope with stale values. You can cache the result of COUNT(*) in your DAO layer and make that layer intelligently expunge the cache when you run DELETE or INSERT statements, but that assumes nothing external to your DAO layer will be touching the database and that you're not clustering your application. You can make the above cluster-safe by mixing in JGroups or JMS or something else that can send clustered cache invalidations around the place, but you still have external modification issues. You can combine the above with cache timeouts to give you a blend of both, and tune the rate of invalidation messages (you could group multiple entity invalidations into a single message) and also tune the timeout values to give an acceptable trade-off between data staleness and speed. This trade-off will be different depending on lots of factors, including what sort of data you're displaying, how big a performance bottleneck this really is (ideally you want realtime updates, so have you profiled it to make sure you really need to cache things and serve potentially stale data yet?). See, there is no optimal way. If the above confuses you, just do what 99% of people will do, and rely on your MySQL or whatever to cache the value for you and don't worry about it. If you're really concerned, you can profile your application and fix the bottlenecks. They probably won't be where you think they will. Premature optimisation is the root of all evil. Al -- Alastair Maw Wicket-biased blog at http://herebebeasties.com ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
