thanks :) It's 00:46 here, I'll try it out in the morning, If I make it work I'll create a wiki page for it...
Davor Hrg On Wed, Mar 19, 2008 at 12:38 AM, Fernando Padilla <[EMAIL PROTECTED]> wrote: > here you go :) > > Should be able to drop these into your project. > > The Buffer.java is the component ( so somewhere under components package > ), and the BufferServices needs to go somewhere where Tapestry will not > enhance it, so I put it under the services package. ). :) Sorry, but > the "cacheKey/Extra" stuff is a little confusing, but maybe we can start > a different thread/docs for that, or simplify to make it easier for > generalization.. > > The Parameters are: > > 1) timeout: String > a duration in which a cache value will be valid; format: "hh:mm:ss" > if you want a one hour timeout: "01:00:00". > if you want a 30 min timeout: "00:30:00" > > 2) lastUpdated: Date > it output this parameter (if bound), to let you know when the contents > of the Buffer were last updated. So you can print out a small message > "Last Updated ######" > > > 3) cacheKey: String > 4) cacehKeyExtra: String > > here is where it might get a little confusing.. it generates a key > into the cache using the request server/port/context/path and cacheKey > and cacheKeyExtra. So it focuses the cache onto the current server > and webapp ( since we used a shared memcache this avoids developers > and production webapps stepping on each others toes ). It then > adds cacheKey (which defaults to the component's extendedId), and > cacheKeyExtra (which defaults to empty). > > So by default just wrapping your stuff with <buffer timeout> will just > work since the key will be something like > "server:port/context_PageName:buffer_#". > > You would set cacheKey if you wanted to generalize the contents of the > buffer ( have the same Buffer component shared across pages ). > > You would set cacheKeyExtra if you wanted to specialize the contents of > the buffer ( have the same Buffer component apply to subsets of > request.. like if it's user specific ). > > > > > > > > > > > Davor Hrg wrote: > > I'm interested in the one for T5 :) > > > > if you are not allowed to share source, > > maybe few hints how to make it > > > > Davor Hrg > > > > On Tue, Mar 18, 2008 at 7:22 PM, Fernando Padilla <[EMAIL PROTECTED]> > wrote: > >> We have a component that we call "Buffer" :) it takes a timeout, > >> optional cachekey, and optional lastmodified (to tell you) > >> > >> We have it for Tap4 and Tap5, if anyone really wants it, I bet I can > >> liberate it.. you would just have to change the cache hooks to use > >> whatever cache you want to use... > >> > >> The easiest way to add caching to the app. :) > >> > >> > >> > >> Martin Kersten wrote: > >> > @Chached is only used during a single page rendering cycle. It would > not > >> > apply to your situation. (as far as I know) > >> > > >> > Source: > >> > http://sqllyw.wordpress.com/2008/03/15/new-features-in-tapestry-5011/ > >> > > >> > Your scenario would be implementable using your own component. > >> > The component would represent a fragment and read the file (even > >> > use a inmemory cache strategy (soft/weakreferences)) and write > >> > the ouput directly to stream (or actually the dom tree of your > >> > document being returned). > >> > > >> > Using your own solution enables you to mimic the behavior you talk > about. > >> > Another idea would to write / cache only datas needed to render the > tables > >> > (e.g. cache only content not markup). Never the less I am in doupt, > >> > if such a solution is necessary (dynamically cache results of > >> > database queries in memory or on disk). > >> > > >> > So after all you might want to port your application. As always use > >> > the simpliest solution first. So database queries without any caches. > >> > Once you see any problems (performance is below required) just go for > >> > optimization. Since you have a fallback solution at hand (cron-jobs + > >> > disk fragments) you are at the safe side. But I am in doupt if you > >> > really need the markup being cached. Caching the database results > >> > and recreate markup sounds more reasonable. You might save you lots > >> > of seeking time. > >> > > >> > But you always know: Only the code / application will tell you! > >> > > >> > > >> > Cheers, > >> > > >> > Martin (Kersten) > >> > > >> > -----Ursprüngliche Nachricht----- > >> > Von: Tobias Marx [mailto:[EMAIL PROTECTED] > >> > Gesendet: Dienstag, 18. März 2008 17:45 > >> > An: Tapestry users > >> > Betreff: @Cached and caching in general > >> > > >> > I have not used T5 yet, but would @Cached use the file system for > caching HTML fragments similiar to caching mechanisms in some php frameworks? > >> > > >> > Or is this a pure memory-based cache? > >> > > >> > I am thinking about migrating an old PHP application to T5 - it has > really a lot of traffic and any users are logged in at the same time. > >> > > >> > It is quite a low-level application that is still quite fast due to > cron jobs in the background that generate HTML fragments that are included to > reduce the database-query bottleneck (e.g. grouping/ordering and sorting of > huge tables). > >> > > >> > Somehow I don't trust Hibernate for high-performance database queries > on huge tables .... as I think if tables are huge and many people access it, > it will always lead to problems...no matter how good the queries are and how > well you have splitted the data across several tables. > >> > > >> > So I think the best solution is always to generate HTML fragments in > the background that take a long time and simple "include" them....this is > even quicker then parsing templates when the data is cached. So you save the > time necessary for querying the database plus the time necessary for > processing the templates that are involved. > >> > > >> > Currently the setup on this application uses one-way database > replication and the cron jobs access the the huge data table on the > replicated database and generate those HTML fragments without disturbing the > web-applications performance. So the main application simply includes those > HTML fragments within milliseconds. > >> > > >> > But maybe the T5 caching mechanism would make all of those low-level > tricks redundant? > >> > > >> > --------------------------------------------------------------------- > >> > 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]
