Re: Clear PersistentFieldConduit cached value
Figured it out. You can invoke the conduit_set_[fieldname] method using reflection (declared, not regular) and this will reflect the value in the PerthreadMap. This function takes a singular argument with the type of the field. Cheers On Mon, Dec 12, 2016 at 5:45 PM, David Diazwrote: > Hi all, > > I am trying to set a persistent value of a field in my application on a > XHR request. I am using tynamo's tapestry-conversation and I want to copy > the old conversation's values to the new conversation. I am iterating > through each field in the old conversation and setting the value for the > new conversation like so: > >> Session session = request.getSession(false); >> for (String name : session.getAttributeNames(oldConversationPrefix)) >>session.setAttribute(name.replace(oldConversationPrefix, > newConversationPrefix), session.getAttribute(name) > > However once the XHR request completes the changes aren't shown in the > render. If I update the XHR again after this has been done with another > request (i.e click on something on the page) then the values are actually > updated and I see what I expect. > > I looked into why this is happening and it seems like whenever a field is > accessed it goes into the PerthreadMap for the specific field and grabs the > value that was generated when the page was first rendered. Since it only > does it at the start of the render any changes to the field don't seem to > be reflected until the next render. > > I've tried: > * Setting the field using reflection > * Using InternalComponentResourcesImpl.persistFieldChange > * Trying to find a way to run the conduit_get_[fieldname] method to > modify the PersistentFieldConduit value, but I couldn't figure this out > > Any help would be appreciated... this has stumped me! I'm sure I'm just > doing something wrong and I've been missing something that's obvious. > > Thanks, > David >
Clear PersistentFieldConduit cached value
Hi all, I am trying to set a persistent value of a field in my application on a XHR request. I am using tynamo's tapestry-conversation and I want to copy the old conversation's values to the new conversation. I am iterating through each field in the old conversation and setting the value for the new conversation like so: > Session session = request.getSession(false); > for (String name : session.getAttributeNames(oldConversationPrefix)) >session.setAttribute(name.replace(oldConversationPrefix, newConversationPrefix), session.getAttribute(name) However once the XHR request completes the changes aren't shown in the render. If I update the XHR again after this has been done with another request (i.e click on something on the page) then the values are actually updated and I see what I expect. I looked into why this is happening and it seems like whenever a field is accessed it goes into the PerthreadMap for the specific field and grabs the value that was generated when the page was first rendered. Since it only does it at the start of the render any changes to the field don't seem to be reflected until the next render. I've tried: * Setting the field using reflection * Using InternalComponentResourcesImpl.persistFieldChange * Trying to find a way to run the conduit_get_[fieldname] method to modify the PersistentFieldConduit value, but I couldn't figure this out Any help would be appreciated... this has stumped me! I'm sure I'm just doing something wrong and I've been missing something that's obvious. Thanks, David
@Cached
does @Cached work in only pages, or should it work in components too?
Re: @Cached
It works both in pages and components. On Fri, Dec 6, 2013 at 2:20 PM, John j...@quivinco.com wrote: does @Cached work in only pages, or should it work in components too?
Re: @Cached
On Fri, 06 Dec 2013 11:33:05 -0200, Dusko Jovanovski dusk...@gmail.com wrote: It works both in pages and components. Just remember that @Cached only caches method return values during a request, but not between requests. I'm planning to do provide some caching (not just in a single thread) in for Tapestry-IoC and Tapestry someday next year. Pages, for the most part, *are* components, but with just few differences: * You cannot use a page inside another page, while components can be used inside other components. * Pages have URLs, components don't. * Components have parameters, pages don't. * Pages have activation context, components don't. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br Help me spend a whole month working on Tapestry bug fixes and improvements: http://igg.me/at/t5month - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Page is getting cached in Tapestry 5.0.18
On Sat, 15 Oct 2011 07:54:18 -0300, ManuPK manupk.t...@gmail.com wrote: I am using tapestry version 5.0.18. In my application the tapestry pages are getting cached. ie, when I hit the URL to load the page the request is not reaching the server. I need to press ctrl+F5 to get the valid page. Is it because of the page pooling? No. This is browser behavior. Or how can I make sure always the request is reached the server and the fresh data is loaded to the page. There's no 100% guaranteed way, but you can use Wulf's suggestions. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Page is getting cached in Tapestry 5.0.18
Thanks Thiago and Wulf's for helping. I don't get this issue every time but happens too-often in some machines and pages. Is there any settings possible in browser? If I use the no-cache attributes even t he images will not be cached? Will it create any performance issue? - Thanks, Manu PK -- View this message in context: http://tapestry.1045711.n5.nabble.com/Page-is-getting-cached-in-Tapestry-5-0-18-tp4905016p4910658.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Page is getting cached in Tapestry 5.0.18
I am using tapestry version 5.0.18. In my application the tapestry pages are getting cached. ie, when I hit the URL to load the page the request is not reaching the server. I need to press ctrl+F5 to get the valid page. Is it because of the page pooling? Or how can I make sure always the request is reached the server and the fresh data is loaded to the page. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Page-is-getting-cached-in-Tapestry-5-0-18-tp4905016p4905016.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Page is getting cached in Tapestry 5.0.18
If the request isn't initiated by the browser to the server, then shouldn't this be a browser issue ? On Sat, Oct 15, 2011 at 12:54 PM, ManuPK manupk.t...@gmail.com wrote: I am using tapestry version 5.0.18. In my application the tapestry pages are getting cached. ie, when I hit the URL to load the page the request is not reaching the server. I need to press ctrl+F5 to get the valid page. Is it because of the page pooling? Or how can I make sure always the request is reached the server and the fresh data is loaded to the page. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Page-is-getting-cached-in-Tapestry-5-0-18-tp4905016p4905016.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- *Regards,* *Muhammad Gelbana Java Developer*
RE: Page is getting cached in Tapestry 5.0.18
Hi Manu, It helps to set the following meta tags: meta content=NO-CACHE http-equiv=CACHE-CONTROL meta content=NO-CACHE http-equiv=PRAGMA META HTTP-EQUIV=Expires CONTENT=-1 Kind Regards, Wulf -Original Message- From: ManuPK [mailto:manupk.t...@gmail.com] Sent: Samstag, 15. Oktober 2011 12:54 To: users@tapestry.apache.org Subject: Page is getting cached in Tapestry 5.0.18 I am using tapestry version 5.0.18. In my application the tapestry pages are getting cached. ie, when I hit the URL to load the page the request is not reaching the server. I need to press ctrl+F5 to get the valid page. Is it because of the page pooling? Or how can I make sure always the request is reached the server and the fresh data is loaded to the page. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Page-is-getting-cached-in-Tapestry-5-0-18-tp4905016p4905016.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
T5: @Cached(watch) parameter requires public property
Hi Again - Is there a specific reason why watch parameter for @Cached annotation requires public property when using default prop binding? This is an inconvenient limitation IMO, as I don't necessarily want to expose my watch property publicly. For example, my watch on getShoppingCart may be something like this: @Cached(watch=cartWatch) public ShoppingCartBean getShoppingCart() { Long userId = getUserId(); Long cartId = getCartId(); log.debug(cartId: {}, userId: {}, cartId, userId); return cartService.findShoppingCart(cartId, userId); } private long getCartWatch() { Long userId = getUserId(); Long cartId = getCartId(); if(userId == null) userId = 0L; if(cartId == null) cartId = 0L; return userId + cartId; } Minor issue, but unless there is a strict reason behind it, I thing watch should allow any scope. Adam - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: @Cached(watch) parameter requires public property
On Thu, 28 Apr 2011 17:38:01 -0300, Adam Zimowski zimowsk...@gmail.com wrote: Hi Again - Hi! Is there a specific reason why watch parameter for @Cached annotation requires public property when using default prop binding? I'd guess the JVM bytecode verifier would complain about invalid access, as the prop binding generates its classes outside the page class. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
@Cached method called multiple times
Hello everyone! I am using Tapestry 5.1.5 and I noticed that a method annotated as @Cached is executed several times for a single pageview. I am using a BaseComponent class that contains this method. It is called from component that extends this. Or is it possible @Cached is not working when debugging with Jetty? Thanks! Tobias - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: @Cached method called multiple times
On Mon, 04 Oct 2010 14:18:19 -0300, Tobias Marx tmar...@gmx.de wrote: Hello everyone! Hi! I am using Tapestry 5.1.5 and I noticed that a method annotated as @Cached is executed several times for a single pageview. I am using a BaseComponent class that contains this method. It is called from component that extends this. I guess you have more than one BaseComponent subclass instance in your page. If so, you're seeing the expected behavior. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
How to flush cached pages for a user when locale is changed
hi I want to flush the cached pages when i change the locale for the user. how can i do that? thanks - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: How to flush cached pages for a user when locale is changed
What r u trying to accomplish? If u want the pages to see the new locale u can use LocalizationSetter service. Normally what i do is to add a PageRenderRequestFilter that obtains the user locale (from database or cookie) and then u just need to call localizationSetter.setLocaleFromLocaleName(locale); This will assure that ur messages will be resolved correctly. I don't think that messing with the page pool is ment for typical use cases but well, maybe u r tying to do something different. I hope it helps. On Tue, Feb 9, 2010 at 3:34 PM, N T R PHANI KUMAR phan...@imaginea.comwrote: hi I want to flush the cached pages when i change the locale for the user. how can i do that? thanks - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
where would I start if I wanted to add support for cached javascript minification?
Where would I start if I wanted to add support for cached javascript minification a la JAWR? I know that Tapestry 5.1 ships with intrinsic support for combined JS files. Does that combination happen on each request? Or is it cached? What of the gzip support? Cached or not cached in memory? Finally, what about taking it one step further -- what if I wanted to use the Yahoo YUI minification routine (opt-in) to then minify and condense these combined javascript files? Where in the user-land sections of the Tapestry framework would I make this contribution? Or, where in Tapestry proper would somebody endeavor to write a patch to add this sort of functionality? I've not done too much spelunking and so I'm really looking for any exploratory information here. Any one else do anything like this? Thanks, Joshua Long http://www.joshlong.com/ - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: where would I start if I wanted to add support for cached javascript minification?
No real answers, but if you want to run jawr 'offline' check out http://github.com/andyhot/maven-jawr-plugin/ or this thread in jawr ML http://markmail.org/message/ef4vtu7xl75fe3ra On Thu, Jun 4, 2009 at 5:56 AM, Josh Long starbux...@gmail.com wrote: Where would I start if I wanted to add support for cached javascript minification a la JAWR? I know that Tapestry 5.1 ships with intrinsic support for combined JS files. Does that combination happen on each request? Or is it cached? What of the gzip support? Cached or not cached in memory? Finally, what about taking it one step further -- what if I wanted to use the Yahoo YUI minification routine (opt-in) to then minify and condense these combined javascript files? Where in the user-land sections of the Tapestry framework would I make this contribution? Or, where in Tapestry proper would somebody endeavor to write a patch to add this sort of functionality? I've not done too much spelunking and so I'm really looking for any exploratory information here. Any one else do anything like this? Thanks, Joshua Long http://www.joshlong.com/ - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Andreas Andreou - andy...@apache.org - http://blog.andyhot.gr Tapestry / Tacos developer Open Source / JEE Consulting - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Cached and Self-Calls
Does tapestry manipulate the page class enough that @Cached affects self-calls? That is, if I wrote this code: @Cached List? getSomeExpensiveResult() { ... } String getSummary() { if( getSomeExpensiveResult().isEmpty() ) return nothing; else { String summary = ; for( Object item : getSomeExpensiveResult() ) { summary += item.toString(); } } } Would getSummary() call getSomeExpensiveResult() twice (as it would if the internals weren't manipulated in some way), or does Tapestry manipulate the class enough that even that kind of use is cached? I've always got @SetupRender as an alternative for calculating something expensive, from what I can tell. - Geoffrey -- Geoffrey Wiseman http://www.geoffreywiseman.ca/
Re: Cached and Self-Calls
I believe self-calls are handled; you can use @Cached on non-public methods as well. On Thu, Mar 26, 2009 at 12:54 PM, Geoffrey Wiseman geoffrey.wise...@gmail.com wrote: Does tapestry manipulate the page class enough that @Cached affects self-calls? That is, if I wrote this code: @Cached List? getSomeExpensiveResult() { ... } String getSummary() { if( getSomeExpensiveResult().isEmpty() ) return nothing; else { String summary = ; for( Object item : getSomeExpensiveResult() ) { summary += item.toString(); } } } Would getSummary() call getSomeExpensiveResult() twice (as it would if the internals weren't manipulated in some way), or does Tapestry manipulate the class enough that even that kind of use is cached? I've always got @SetupRender as an alternative for calculating something expensive, from what I can tell. - Geoffrey -- Geoffrey Wiseman http://www.geoffreywiseman.ca/ -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Cached Annotation watch property seems to use '==' instead of 'equals'
I'm trying to use the '@Cached' annotation with a watch expression to cache results of methods in a form contained within a loop. For some watch expressions, I construct a string, so the code basically looks like @Cached(watch=watchKey) Object getData() { // return data; } String getWatchKey() { return a.toString() + : + b.toString(); } When I do this, though, the cached annotation does not seem to work properly, in that the 'getData()' method is called multiple times in a request. The problem seems to be that '==' is used instead of 'equals' in the code 'CachedWorker' generates to compare the result of the watch expression. Is this intentional, so we need to make sure the watch expression returns the exact same object if we want to use a cached value? Or should it be changed to use 'equals'? Doug - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Cached Annotation watch property seems to use '==' instead of 'equals'
Looks like an oversight to me ... using equals() would make more sense to me as well. It is intended primarily for Hibernate entities, but equals() works there as well, as Hibernate ensures that primary key identity is the same as object identity with a context. Perhaps Dan can shed some light? @Cached was written by Dan Adams. On Mon, Dec 22, 2008 at 4:44 PM, Doug Hauge doug.ha...@lithium.com wrote: I'm trying to use the '@Cached' annotation with a watch expression to cache results of methods in a form contained within a loop. For some watch expressions, I construct a string, so the code basically looks like @Cached(watch=watchKey) Object getData() { // return data; } String getWatchKey() { return a.toString() + : + b.toString(); } When I do this, though, the cached annotation does not seem to work properly, in that the 'getData()' method is called multiple times in a request. The problem seems to be that '==' is used instead of 'equals' in the code 'CachedWorker' generates to compare the result of the watch expression. Is this intentional, so we need to make sure the watch expression returns the exact same object if we want to use a cached value? Or should it be changed to use 'equals'? Doug - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: tacos @Cached in t4
i tried this. whenever i press f5, pagebeginrender will still be called and db will be hit @Persist(session) public abstract Collection getPersistThisOne(); public abstract void setPersistThisOne(Collection persistThisOne); public void pageBeginRender(PageEvent event) { System.out.println(pageBeginRender..); setPersistThisOne( dao.getFromDB()); } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tacos @Cached in t4
I'm sorry, but what do you expect Tapestry to do about that? You're explicity setting the property each time the page is loaded. @Persist doesn't change that. You'll need to check whether or not persistThisOne is not null before assigning to it for this to work. -Filip On 2008-09-07 08:39, michael lim wrote: i tried this. whenever i press f5, pagebeginrender will still be called and db will be hit @Persist(session) public abstract Collection getPersistThisOne(); public abstract void setPersistThisOne(Collection persistThisOne); public void pageBeginRender(PageEvent event) { System.out.println(pageBeginRender..); setPersistThisOne( dao.getFromDB()); } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
tacos @Cached in t4
in my page, i do like below, but when i press refresh F5 on page, i keep on getting database hit. when using cached, aren't it not suppose to call getFromDB() for subsequent call ? @Cached public String getGenerateMenuCached() { return dao.getFromDb(); } //in my dao public String getFromDB(){ System.out.println(hit db); } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tacos @Cached in t4
my .application look like this library id=tacos specification-path=/net/sf/tacos/Tacos.library/ library id=dojo specification-path=/net/sf/tacos/Dojo.library/ library id=comet specification-path=/net/sf/tacos/cometd/Cometd.library/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tacos @Cached in t4
You've misunderstood the purpose of @Cached. The documentation ( http://tacos.sourceforge.net/tacos4.1/tacos-annotations/index.html) says: The Cached http://tacos.sourceforge.net/tacos4.1/apidocs/net/sf/tacos/annotations/Cached.htmlannotation allows you to cache the results of a pag/component method for the lifetime of a single request. It can be attached to any non-private, non-abstract method:. When you press F5 you are creating a new request. You might be looking for @Persist instead; you use it with an abstract property that you populate somewhere else, for example in pageBeginRender. Kalle On Sat, Sep 6, 2008 at 10:03 AM, michael lim [EMAIL PROTECTED] wrote: in my page, i do like below, but when i press refresh F5 on page, i keep on getting database hit. when using cached, aren't it not suppose to call getFromDB() for subsequent call ? @Cached public String getGenerateMenuCached() { return dao.getFromDb(); } //in my dao public String getFromDB(){ System.out.println(hit db); } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tables being cached by IE
Hi, one of our clients has noticed, that when he accesses a simple page with a grid through IE7, hitting the Pagers on the grid does not show the requested Grid-Page but still the old one. Refreshing the page thereafter show the right grid-page. I can imagine that IE is doing some caching here because the URL looks the same after paging through the grid. Is this a known problem with IE? I cannot reproduce this with IE here on my PC though. The Grid is not an inPlace grid. Would it be the right solution to add some HTTP-EQUIV header to tell the browser not to do any caching with that page? For every page containing a grid? M. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @Cached and caching in general
Tobias Marx wrote: Wouldn't it be useful to make the @Cache annotation the default annotation for all methods? I can not imagine a case where it would make sense that during the rendering of a page returns different results... Just an example : you are in a loop (or grid or a beaneditor any other looping component) and you get the current value of an object, for the current iteration. -- Francois Armand Etudes Développements J2EE Groupe Linagora - http://www.linagora.com Tél.: +33 (0)1 58 18 68 28 --- InterLDAP - http://interldap.org FederID - http://www.federid.org/ Open Source identities management and federation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @Cached and caching in general
Yes, you are right. But loops are usually inside of components and pages contain those componentsbut all methods in the page itself could be @Cache methods in my opinion if you do a component based approach and always package logical widgets into a component. Original-Nachricht Datum: Tue, 25 Mar 2008 13:33:19 +0100 Von: Francois Armand [EMAIL PROTECTED] An: Tapestry users users@tapestry.apache.org Betreff: Re: @Cached and caching in general Tobias Marx wrote: Wouldn't it be useful to make the @Cache annotation the default annotation for all methods? I can not imagine a case where it would make sense that during the rendering of a page returns different results... Just an example : you are in a loop (or grid or a beaneditor any other looping component) and you get the current value of an object, for the current iteration. -- Francois Armand Etudes Développements J2EE Groupe Linagora - http://www.linagora.com Tél.: +33 (0)1 58 18 68 28 --- InterLDAP - http://interldap.org FederID - http://www.federid.org/ Open Source identities management and federation - 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]
Re: @Cached and caching in general
[EMAIL PROTECTED] wrote: Yes, you are right. But loops are usually inside of components and pages contain those componentsbut all methods in the page itself could be @Cache methods in my opinion if you do a component based approach and always package logical widgets into a component. That means that if forbid the use of loop in page (for example, a loop through all the high-level widgets of the page) , or at least that the default behaviour for component's or for page's method is not the same... In my opinion, it looks like to be very error prone, with things that just don't work as expected. -- Francois Armand Etudes Développements J2EE Groupe Linagora - http://www.linagora.com Tél.: +33 (0)1 58 18 68 28 --- InterLDAP - http://interldap.org FederID - http://www.federid.org/ Open Source identities management and federation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @Cached and caching in general
caching every method by default is definitely too error prone, and unexpected for most people. On Tue, Mar 25, 2008 at 3:23 PM, Francois Armand [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Yes, you are right. But loops are usually inside of components and pages contain those componentsbut all methods in the page itself could be @Cache methods in my opinion if you do a component based approach and always package logical widgets into a component. That means that if forbid the use of loop in page (for example, a loop through all the high-level widgets of the page) , or at least that the default behaviour for component's or for page's method is not the same... In my opinion, it looks like to be very error prone, with things that just don't work as expected. -- Francois Armand Etudes Développements J2EE Groupe Linagora - http://www.linagora.com Tél.: +33 (0)1 58 18 68 28 --- InterLDAP - http://interldap.org FederID - http://www.federid.org/ Open Source identities management and federation - 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]
AW: AW: @Cached and caching in general
...this king of component is useful for capturing output so it can be sent via email for example. This does not sound like a good idea. Do you mean requesting a page and cut it out or grabbing part of the DOM during same request. Just wondering... . -Ursprüngliche Nachricht- Von: Davor Hrg [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 19. März 2008 10:42 An: Tapestry users Betreff: Re: AW: @Cached and caching in general I agree that this is not something to take on lightly, and data should be cached, and rendering left as is. but besides caching this king of component is useful for capturing output so it can be sent via email for example. I like to keep most things stateless (only dependant on parameters), so from time to time I can use some of these nasty tricks. Davor Hrg On Wed, Mar 19, 2008 at 1:04 AM, Fernando Padilla [EMAIL PROTECTED] wrote: :) True. I definitely won't say that this will solve all cases 100%. But for basic rendering.. this allows you to essentially set expires for fragments of the page. And yes it caches all operations that go through PageRenderSupport. And if I could take over the markupWriter properly, I would have cached and replayed those already.. but i couldn't easily do that.. But on second thought, you're right, maybe I should have cached a DOM tree.. since it would have a much better guarantees for replaying. But on most cases, this component works pretty darn good, and we love it. Of course trying to do evict cache on particular events is hard.. but if you are alright with updates within 30hr sort of cases. this is a good start. Howard Lewis Ship wrote: I'm generally against these approached. Cache the data, make it fast to access. Let Tapestry do a full render every time. You'll end up with confusing, unforseen consequences. Rendering is increasingly a complex dance between components. That's the power and the penalty of Tapestry. Components inside that cached zone are not just rendering a character stream, they are generating JavaScript, assigning unique ids (via PageRenderSupport) interacting with an enclosing Form components, and doing other user-specific things. I would always look elsewhere first for places that need optimization, and I'd start with database access and queries. On Tue, Mar 18, 2008 at 11:22 AM, 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
Re: AW: @Cached and caching in general
Well, i believe if someone is aware of these issues, there's nothing wrong with using this solution - I've had some cases where data access is fast but data processing (in order to present) was quite complex, so this really helped. For reference, another not-yet-mentioned problem of this kind of cache is the jsessionid parameter that may be cached in url (though we / many people completely remove them nowadays) On Wed, Mar 19, 2008 at 1:55 AM, Howard Lewis Ship [EMAIL PROTECTED] wrote: I'm generally against these approached. Cache the data, make it fast to access. Let Tapestry do a full render every time. You'll end up with confusing, unforseen consequences. Rendering is increasingly a complex dance between components. That's the power and the penalty of Tapestry. Components inside that cached zone are not just rendering a character stream, they are generating JavaScript, assigning unique ids (via PageRenderSupport) interacting with an enclosing Form components, and doing other user-specific things. I would always look elsewhere first for places that need optimization, and I'd start with database access and queries. On Tue, Mar 18, 2008 at 11:22 AM, 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 themthis 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
Re: AW: @Cached and caching in general
I mean exactly that, I'm comfortable with my html code, css and js I can inline what I need, I'm not proposing this as a general approach, but I like doing just that: take part of rendered content and do something with it. if something is a compoenent framework, a component should be independant, even after the html code is rendered. Davor Hrg On Wed, Mar 19, 2008 at 10:45 AM, Martin Kersten [EMAIL PROTECTED] wrote: ...this king of component is useful for capturing output so it can be sent via email for example. This does not sound like a good idea. Do you mean requesting a page and cut it out or grabbing part of the DOM during same request. Just wondering... . -Ursprüngliche Nachricht- Von: Davor Hrg [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 19. März 2008 10:42 An: Tapestry users Betreff: Re: AW: @Cached and caching in general I agree that this is not something to take on lightly, and data should be cached, and rendering left as is. but besides caching this king of component is useful for capturing output so it can be sent via email for example. I like to keep most things stateless (only dependant on parameters), so from time to time I can use some of these nasty tricks. Davor Hrg On Wed, Mar 19, 2008 at 1:04 AM, Fernando Padilla [EMAIL PROTECTED] wrote: :) True. I definitely won't say that this will solve all cases 100%. But for basic rendering.. this allows you to essentially set expires for fragments of the page. And yes it caches all operations that go through PageRenderSupport. And if I could take over the markupWriter properly, I would have cached and replayed those already.. but i couldn't easily do that.. But on second thought, you're right, maybe I should have cached a DOM tree.. since it would have a much better guarantees for replaying. But on most cases, this component works pretty darn good, and we love it. Of course trying to do evict cache on particular events is hard.. but if you are alright with updates within 30hr sort of cases. this is a good start. Howard Lewis Ship wrote: I'm generally against these approached. Cache the data, make it fast to access. Let Tapestry do a full render every time. You'll end up with confusing, unforseen consequences. Rendering is increasingly a complex dance between components. That's the power and the penalty of Tapestry. Components inside that cached zone are not just rendering a character stream, they are generating JavaScript, assigning unique ids (via PageRenderSupport) interacting with an enclosing Form components, and doing other user-specific things. I would always look elsewhere first for places that need optimization, and I'd start with database access and queries. On Tue, Mar 18, 2008 at 11:22 AM, 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
@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 themthis 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]
Re: @Cached and caching in general
@Cached is an annotation that caches method call result per request. so while page is rendering if multiple pieces of template require that property it gets called only once... Davor Hrg On Tue, Mar 18, 2008 at 5:44 PM, Tobias Marx [EMAIL PROTECTED] wrote: 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 themthis 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]
Re: @Cached and caching in general
@Cache works on per request basis, so that anything you return from a method which has @Cache annotation will get actually built or retrieved only once - but only once per http request. So if you're building an expensive HTML fragment: @Cached public String buildExpensiveHtmlFragment() { //. } during a request of a single thread you can call buildExpensiveHtmlFragment() as many times as you want with a full confidence that the work to build it would be performed only once. When you refresh the page, the build will be invoked once again (but once only). -adam On Tue, Mar 18, 2008 at 11:44 AM, Tobias Marx [EMAIL PROTECTED] wrote: 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 themthis 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]
Re: @Cached and caching in general
Ok. Thanks...this is what I wanted to know. What about an annotation for components/pages ? @CachedOutput (time=3600) In this case a component or page would not render itself every time but cache its output to the filesystem (a cache directory). Every hour it would re-generate/refresh its output and this way save lots of performance. Original-Nachricht Datum: Tue, 18 Mar 2008 17:52:11 +0100 Von: Davor Hrg [EMAIL PROTECTED] An: Tapestry users users@tapestry.apache.org Betreff: Re: @Cached and caching in general @Cached is an annotation that caches method call result per request. so while page is rendering if multiple pieces of template require that property it gets called only once... Davor Hrg On Tue, Mar 18, 2008 at 5:44 PM, Tobias Marx [EMAIL PROTECTED] wrote: 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 themthis 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]
AW: @Cached and caching in general
The problem is context I guess. Usally your component depends on lots of stuff. Parameters, URL, Services, Page-state, component state, HTTP-Parameters and so on. Providing such a low-level cache might sound reasonable but remembering my own requirements lots of days back (2001) the cache depended on a flag system being triggered by distributed actions. If you need your own cache (being driven that way) you might want to create your own component (check out the rendering pipe) t:cached timeout=360 pMy Content to cache/p /t:cached Please report your findings. But I am in doupt such a general caching service is needed. But as far as I know Tapestry and its agility, all you need -Ursprüngliche Nachricht- Von: Tobias Marx [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 18. März 2008 17:58 An: Tapestry users Betreff: Re: @Cached and caching in general Ok. Thanks...this is what I wanted to know. What about an annotation for components/pages ? @CachedOutput (time=3600) In this case a component or page would not render itself every time but cache its output to the filesystem (a cache directory). Every hour it would re-generate/refresh its output and this way save lots of performance. Original-Nachricht Datum: Tue, 18 Mar 2008 17:52:11 +0100 Von: Davor Hrg [EMAIL PROTECTED] An: Tapestry users users@tapestry.apache.org Betreff: Re: @Cached and caching in general @Cached is an annotation that caches method call result per request. so while page is rendering if multiple pieces of template require that property it gets called only once... Davor Hrg On Tue, Mar 18, 2008 at 5:44 PM, Tobias Marx [EMAIL PROTECTED] wrote: 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 themthis 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]
AW: @Cached and caching in general
My theory is that such a disk-caching behaviour could speed up Tapestry applications by factor 100although Tapestry 5 is quite fast. The template parsing is still quite slow because it uses Velocity and everything that avoids template parsing would increase the speed a lot. Original-Nachricht Datum: Tue, 18 Mar 2008 18:01:40 +0100 Von: Martin Kersten [EMAIL PROTECTED] An: Tapestry users users@tapestry.apache.org Betreff: AW: @Cached and caching in general @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 themthis 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]
Re: @Cached and caching in general
Tapestry already does some caching on invariant properties, and when it doesn't the overhead of actually reading the property again is negligible unless it result in a database query etc. Also, I have plenty of pages where properties change while rendering the page. So, no. It wouldn't be useful. -Filip On 2008-03-18 18:01, Tobias Marx wrote: Wouldn't it be useful to make the @Cache annotation the default annotation for all methods? I can not imagine a case where it would make sense that during the rendering of a page returns different results... Original-Nachricht Datum: Tue, 18 Mar 2008 11:53:09 -0500 Von: Adam Zimowski [EMAIL PROTECTED] An: Tapestry users users@tapestry.apache.org Betreff: Re: @Cached and caching in general @Cache works on per request basis, so that anything you return from a method which has @Cache annotation will get actually built or retrieved only once - but only once per http request. So if you're building an expensive HTML fragment: @Cached public String buildExpensiveHtmlFragment() { //. } during a request of a single thread you can call buildExpensiveHtmlFragment() as many times as you want with a full confidence that the work to build it would be performed only once. When you refresh the page, the build will be invoked once again (but once only). -adam On Tue, Mar 18, 2008 at 11:44 AM, Tobias Marx [EMAIL PROTECTED] wrote: 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 themthis 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]
Re: AW: @Cached and caching in general
A factor 100?? C'mon. If, and I stress IF, your application would benefit that much from this, fine. But Tapestry 5 applications in general would - I guarantee you - not see such an improvement. -Filip On 2008-03-18 18:07, Tobias Marx wrote: My theory is that such a disk-caching behaviour could speed up Tapestry applications by factor 100although Tapestry 5 is quite fast. The template parsing is still quite slow because it uses Velocity and everything that avoids template parsing would increase the speed a lot. Original-Nachricht Datum: Tue, 18 Mar 2008 18:01:40 +0100 Von: Martin Kersten [EMAIL PROTECTED] An: Tapestry users users@tapestry.apache.org Betreff: AW: @Cached and caching in general @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 themthis 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]
AW: @Cached and caching in general
The problem is context I guess. Usally your component depends on lots of stuff. Parameters, URL, Services, Page-state, component state, HTTP-Parameters and so on. Yes...but it must be possible somehow as some PHP template engines also do it. Isn't there already some mechanism in the internals of Tapestry that keeps track of that even now? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: @Cached and caching in general
Ok...let's say factor 10 (unless you have many loops inside of loops inside of loops that use queries on large tables). Original-Nachricht Datum: Tue, 18 Mar 2008 18:14:28 +0100 Von: Filip S. Adamsen [EMAIL PROTECTED] An: Tapestry users users@tapestry.apache.org Betreff: Re: AW: @Cached and caching in general A factor 100?? C'mon. If, and I stress IF, your application would benefit that much from this, fine. But Tapestry 5 applications in general would - I guarantee you - not see such an improvement. -Filip On 2008-03-18 18:07, Tobias Marx wrote: My theory is that such a disk-caching behaviour could speed up Tapestry applications by factor 100although Tapestry 5 is quite fast. The template parsing is still quite slow because it uses Velocity and everything that avoids template parsing would increase the speed a lot. Original-Nachricht Datum: Tue, 18 Mar 2008 18:01:40 +0100 Von: Martin Kersten [EMAIL PROTECTED] An: Tapestry users users@tapestry.apache.org Betreff: AW: @Cached and caching in general @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 themthis 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
AW: @Cached and caching in general
You might want to know what tapestry does with your templates. Tapestry reads your template and parses it - only once it changes! So generating two pages (even with different content) just results in using a parsed, preprocessed in memory representation of your template. So tapestry strictly avoids disk-access and parsing in production (when processing all templates on startup is enabled). So there is no need for the older cache it hack. As I mentioned it is easy to play with your own cache implementation. But be carefull about the components you place inside your cache. You know context and event handling. But for displaying 'cached' content it might be an option. If you go ahead and try it you may post your benchmarks. I don't know who has stretched it before but I guess caching is always a hot topic so if you can provide new insides your are welcome. Cheers, Martin (Kersten) -Ursprüngliche Nachricht- Von: Tobias Marx [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 18. März 2008 18:15 An: Tapestry users Betreff: AW: @Cached and caching in general The problem is context I guess. Usally your component depends on lots of stuff. Parameters, URL, Services, Page-state, component state, HTTP-Parameters and so on. Yes...but it must be possible somehow as some PHP template engines also do it. Isn't there already some mechanism in the internals of Tapestry that keeps track of that even now? - 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]
Re: AW: @Cached and caching in general
That's a special case, really. Do what you want. -Filip On 2008-03-18 18:20, Tobias Marx wrote: Ok...let's say factor 10 (unless you have many loops inside of loops inside of loops that use queries on large tables). Original-Nachricht Datum: Tue, 18 Mar 2008 18:14:28 +0100 Von: Filip S. Adamsen [EMAIL PROTECTED] An: Tapestry users users@tapestry.apache.org Betreff: Re: AW: @Cached and caching in general A factor 100?? C'mon. If, and I stress IF, your application would benefit that much from this, fine. But Tapestry 5 applications in general would - I guarantee you - not see such an improvement. -Filip On 2008-03-18 18:07, Tobias Marx wrote: My theory is that such a disk-caching behaviour could speed up Tapestry applications by factor 100although Tapestry 5 is quite fast. The template parsing is still quite slow because it uses Velocity and everything that avoids template parsing would increase the speed a lot. Original-Nachricht Datum: Tue, 18 Mar 2008 18:01:40 +0100 Von: Martin Kersten [EMAIL PROTECTED] An: Tapestry users users@tapestry.apache.org Betreff: AW: @Cached and caching in general @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 themthis 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
AW: @Cached and caching in general
@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 themthis 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]
Re: @Cached and caching in general
Wouldn't it be useful to make the @Cache annotation the default annotation for all methods? I can not imagine a case where it would make sense that during the rendering of a page returns different results... Original-Nachricht Datum: Tue, 18 Mar 2008 11:53:09 -0500 Von: Adam Zimowski [EMAIL PROTECTED] An: Tapestry users users@tapestry.apache.org Betreff: Re: @Cached and caching in general @Cache works on per request basis, so that anything you return from a method which has @Cache annotation will get actually built or retrieved only once - but only once per http request. So if you're building an expensive HTML fragment: @Cached public String buildExpensiveHtmlFragment() { //. } during a request of a single thread you can call buildExpensiveHtmlFragment() as many times as you want with a full confidence that the work to build it would be performed only once. When you refresh the page, the build will be invoked once again (but once only). -adam On Tue, Mar 18, 2008 at 11:44 AM, Tobias Marx [EMAIL PROTECTED] wrote: 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 themthis 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]
AW: @Cached and caching in general
I had the idea while looking at this benchmark here: http://www.dmst.aueb.gr/dds/pubs/conf/2002-SANE-DynCont/html/throughput.gif I am currently trying out Resin as it allows to use PHP and Servlets at the same time - so you can mix old PHP code with Tapestry on a single webserver and replace parts of the web application with PHP or Tapestry depending on whats faster in a certain situation. A typical example I have problems with in Tapestry/Hibernate is the following: - a table that displays an object - buttons or additional components on the table cells that depend on other objects In this case you have several database queriesone for the outer loop and one for the inner loops. In theory you could define a virtual new object in Hibernate that does some joins or unions that will result in just one query in the outer loop...and then it works quite fast. I like Hibernate as long as you can use your objects directly...but using Hibernate for joins and unions is not much fun So such a table would benefit a lot if is was cached...even if the individual queries would be cached you still had to do all the loops and parsing of the templates. Original-Nachricht Datum: Tue, 18 Mar 2008 18:22:01 +0100 Von: Martin Kersten [EMAIL PROTECTED] An: Tapestry users users@tapestry.apache.org Betreff: AW: @Cached and caching in general You might want to know what tapestry does with your templates. Tapestry reads your template and parses it - only once it changes! So generating two pages (even with different content) just results in using a parsed, preprocessed in memory representation of your template. So tapestry strictly avoids disk-access and parsing in production (when processing all templates on startup is enabled). So there is no need for the older cache it hack. As I mentioned it is easy to play with your own cache implementation. But be carefull about the components you place inside your cache. You know context and event handling. But for displaying 'cached' content it might be an option. If you go ahead and try it you may post your benchmarks. I don't know who has stretched it before but I guess caching is always a hot topic so if you can provide new insides your are welcome. Cheers, Martin (Kersten) -Ursprüngliche Nachricht- Von: Tobias Marx [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 18. März 2008 18:15 An: Tapestry users Betreff: AW: @Cached and caching in general The problem is context I guess. Usally your component depends on lots of stuff. Parameters, URL, Services, Page-state, component state, HTTP-Parameters and so on. Yes...but it must be possible somehow as some PHP template engines also do it. Isn't there already some mechanism in the internals of Tapestry that keeps track of that even now? - 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]
Re: AW: @Cached and caching in general
Tobias is right to ask about his, I'm usin php for a long time now and output_buffer functions ob_* are great for simplifying complex pages, adding caching without interferring with internal code people have asked about getting html output of page and etc. if framework would allow access to markup on afterRenderTemplate and if markup could be forced to serialize all HTML of the current element it would allow creating a simple component that can wrap a part of (processor heavy) code and catch the rendered markup. Then it would allow it self to be rendered normaly only in some intervals and produce cached raw output otherwise. this would be very similar to output_buffer tricks in php. Davor Hrg On Tue, Mar 18, 2008 at 6:25 PM, Filip S. Adamsen [EMAIL PROTECTED] wrote: That's a special case, really. Do what you want. -Filip On 2008-03-18 18:20, Tobias Marx wrote: Ok...let's say factor 10 (unless you have many loops inside of loops inside of loops that use queries on large tables). Original-Nachricht Datum: Tue, 18 Mar 2008 18:14:28 +0100 Von: Filip S. Adamsen [EMAIL PROTECTED] An: Tapestry users users@tapestry.apache.org Betreff: Re: AW: @Cached and caching in general A factor 100?? C'mon. If, and I stress IF, your application would benefit that much from this, fine. But Tapestry 5 applications in general would - I guarantee you - not see such an improvement. -Filip On 2008-03-18 18:07, Tobias Marx wrote: My theory is that such a disk-caching behaviour could speed up Tapestry applications by factor 100although Tapestry 5 is quite fast. The template parsing is still quite slow because it uses Velocity and everything that avoids template parsing would increase the speed a lot. Original-Nachricht Datum: Tue, 18 Mar 2008 18:01:40 +0100 Von: Martin Kersten [EMAIL PROTECTED] An: Tapestry users users@tapestry.apache.org Betreff: AW: @Cached and caching in general @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 themthis 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
RE: @Cached and caching in general
Hibernate makes it easy to do some really interesting things without a great deal of thought. Any time you start working with large data sets you have to think carefully about what Hibernate is doing on your behalf - like the inner loop example. For some reporting tasks, you might want to use Hibernate to generate a recordset from raw SQL. For other cases, changing a fetch strategy from LAZY to EAGER will address the performance issues. A substitute for your existing caching, depending on memory requirements, might be to implement a results-cache as a service within your Tapestry app. Mimic what is done currently, but perhaps schedule refreshes with Quartz and keep it within the same app. Jonathan -Original Message- From: Tobias Marx [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 18, 2008 1:35 PM To: Tapestry users Subject: AW: @Cached and caching in general I had the idea while looking at this benchmark here: http://www.dmst.aueb.gr/dds/pubs/conf/2002-SANE- DynCont/html/throughput.gif I am currently trying out Resin as it allows to use PHP and Servlets at the same time - so you can mix old PHP code with Tapestry on a single webserver and replace parts of the web application with PHP or Tapestry depending on whats faster in a certain situation. A typical example I have problems with in Tapestry/Hibernate is the following: - a table that displays an object - buttons or additional components on the table cells that depend on other objects In this case you have several database queriesone for the outer loop and one for the inner loops. In theory you could define a virtual new object in Hibernate that does some joins or unions that will result in just one query in the outer loop...and then it works quite fast. I like Hibernate as long as you can use your objects directly...but using Hibernate for joins and unions is not much fun So such a table would benefit a lot if is was cached...even if the individual queries would be cached you still had to do all the loops and parsing of the templates. Original-Nachricht Datum: Tue, 18 Mar 2008 18:22:01 +0100 Von: Martin Kersten [EMAIL PROTECTED] An: Tapestry users users@tapestry.apache.org Betreff: AW: @Cached and caching in general You might want to know what tapestry does with your templates. Tapestry reads your template and parses it - only once it changes! So generating two pages (even with different content) just results in using a parsed, preprocessed in memory representation of your template. So tapestry strictly avoids disk-access and parsing in production (when processing all templates on startup is enabled). So there is no need for the older cache it hack. As I mentioned it is easy to play with your own cache implementation. But be carefull about the components you place inside your cache. You know context and event handling. But for displaying 'cached' content it might be an option. If you go ahead and try it you may post your benchmarks. I don't know who has stretched it before but I guess caching is always a hot topic so if you can provide new insides your are welcome. Cheers, Martin (Kersten) -Ursprüngliche Nachricht- Von: Tobias Marx [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 18. März 2008 18:15 An: Tapestry users Betreff: AW: @Cached and caching in general The problem is context I guess. Usally your component depends on lots of stuff. Parameters, URL, Services, Page-state, component state, HTTP-Parameters and so on. Yes...but it must be possible somehow as some PHP template engines also do it. Isn't there already some mechanism in the internals of Tapestry that keeps track of that even now? - 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]
Re: AW: @Cached and caching in general
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 themthis 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]
Re: AW: @Cached and caching in general
I had done http://andyhot.di.uoa.gr/tapfx/app?service=page/Cache for T3 and T4 @ http://tapfx.sourceforge.net/ but it needed ehcache Perhaps combine the two (esp. since there's no T5 version) and move to tacos? On Tue, Mar 18, 2008 at 8: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 themthis 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] -- Andreas Andreou - [EMAIL PROTECTED] - http://blog.andyhot.gr Tapestry / Tacos developer Open Source / JEE Consulting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: @Cached and caching in general
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 themthis 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]
Re: AW: @Cached and caching in general
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
Re: @Cached and caching in general
Nope. It's dangerous stuff that should be used with care. On Tue, Mar 18, 2008 at 10:01 AM, Tobias Marx [EMAIL PROTECTED] wrote: Wouldn't it be useful to make the @Cache annotation the default annotation for all methods? I can not imagine a case where it would make sense that during the rendering of a page returns different results... Original-Nachricht Datum: Tue, 18 Mar 2008 11:53:09 -0500 Von: Adam Zimowski [EMAIL PROTECTED] An: Tapestry users users@tapestry.apache.org Betreff: Re: @Cached and caching in general @Cache works on per request basis, so that anything you return from a method which has @Cache annotation will get actually built or retrieved only once - but only once per http request. So if you're building an expensive HTML fragment: @Cached public String buildExpensiveHtmlFragment() { //. } during a request of a single thread you can call buildExpensiveHtmlFragment() as many times as you want with a full confidence that the work to build it would be performed only once. When you refresh the page, the build will be invoked once again (but once only). -adam On Tue, Mar 18, 2008 at 11:44 AM, Tobias Marx [EMAIL PROTECTED] wrote: 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 themthis 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] -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: @Cached and caching in general
I'm generally against these approached. Cache the data, make it fast to access. Let Tapestry do a full render every time. You'll end up with confusing, unforseen consequences. Rendering is increasingly a complex dance between components. That's the power and the penalty of Tapestry. Components inside that cached zone are not just rendering a character stream, they are generating JavaScript, assigning unique ids (via PageRenderSupport) interacting with an enclosing Form components, and doing other user-specific things. I would always look elsewhere first for places that need optimization, and I'd start with database access and queries. On Tue, Mar 18, 2008 at 11:22 AM, 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 themthis 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] -- Howard M. Lewis Ship Creator
Re: AW: @Cached and caching in general
:) True. I definitely won't say that this will solve all cases 100%. But for basic rendering.. this allows you to essentially set expires for fragments of the page. And yes it caches all operations that go through PageRenderSupport. And if I could take over the markupWriter properly, I would have cached and replayed those already.. but i couldn't easily do that.. But on second thought, you're right, maybe I should have cached a DOM tree.. since it would have a much better guarantees for replaying. But on most cases, this component works pretty darn good, and we love it. Of course trying to do evict cache on particular events is hard.. but if you are alright with updates within 30hr sort of cases. this is a good start. Howard Lewis Ship wrote: I'm generally against these approached. Cache the data, make it fast to access. Let Tapestry do a full render every time. You'll end up with confusing, unforseen consequences. Rendering is increasingly a complex dance between components. That's the power and the penalty of Tapestry. Components inside that cached zone are not just rendering a character stream, they are generating JavaScript, assigning unique ids (via PageRenderSupport) interacting with an enclosing Form components, and doing other user-specific things. I would always look elsewhere first for places that need optimization, and I'd start with database access and queries. On Tue, Mar 18, 2008 at 11:22 AM, 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 themthis 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
##T4##Is tapestry service cached?!
i wrote my own service,but i found that when i request a service from one window only first time,i can debug,then every time request the service from the same window will response directly,i cant stop at the break point,the situation like serivice is cached,so ,i want ask does the service i wrote will cached if i dont open a new IE window?if it is , how to disable the cache??thanks a lot! Oliver Lee 2008-03-02
RE: propertyselection not cached
Thanks James, That seems like a viable concern (parameter names versus component id's). I segregated them by postpending PARM to all my parameter names. No relief so I am kinda stuck. form jwcid=[EMAIL PROTECTED] listener=listener:onFormSubmit div jwcid=[EMAIL PROTECTED] block=ognl:components.autoPagingContent/ div jwcid=@RenderBlock block=ognl:components.collectionContent/ div jwcid=[EMAIL PROTECTED] block=ognl:components.autoPagingContent/ /form My headerSelect's select component gets changed but clobbered by my footerSelect's select component. And my footerSelect's select component clobbers my headerSelect's component when their id's are different according to the markup. So I am wondering if it is a tapestry bug. In general I would like to find out how one can update an identical another component on the same page. I could then force this thing to behave correctly. Best regards Ken in nashua From: [EMAIL PROTECTED] To: users@tapestry.apache.org Subject: propertyselection not cached Date: Tue, 9 Oct 2007 15:48:22 -0400 Folks, I have a propertyselection component rigged with 1,2,3,4,5... Everytime I select from my propertyselection... the this.form.submit() listener gets called... but my property gets reset. Nothing sticks... Gallery.JAVA public IPage onFormSubmit (IRequestCycle cycle) { IPage page = cycle.getPage(); return page; } Any ideas? My rendering is fine...Template follows: Best regards Ken in nashua span jwcid=$content$ span jwcid=[EMAIL PROTECTED] table width=100% border=1 tr td width=25% align=left NOWRAP span jwcid=@Insert value=Table Size/ select jwcid=@PropertySelection model=ognl:@[EMAIL PROTECTED] value=ognl:tableSize onchange=javascript:this.form.submit();/select span jwcid=@Insert value=Paging Span/ select jwcid=@PropertySelection model=ognl:@[EMAIL PROTECTED] value=ognl:pagingSpan onchange=javascript:this.form.submit();/select /td td align=left NOWRAP a jwcid=@DirectLink listener=listener:onBegin style=fontSize:15px; span jwcid=@Insert value=/ /a a jwcid=@DirectLink listener=listener:onPrev span jwcid=@Insert value=/ /a a jwcid=@DirectLink listener=listener:onPage parameters=ognl:1 span jwcid=@Insert value=ognl:1/ /a a jwcid=@DirectLink listener=listener:onPage parameters=ognl:2 span jwcid=@Insert value=ognl:2/ /a a jwcid=@DirectLink listener=listener:onPage parameters=ognl:3 span jwcid=@Insert value=ognl:3/ /a a jwcid=@DirectLink listener=listener:onPage parameters=ognl:4 span jwcid=@Insert value=ognl:4/ /a a jwcid=@DirectLink listener=listener:onPage parameters=ognl:5 span jwcid=@Insert value=ognl:5/ /a a jwcid=@DirectLink listener=listener:onNext span jwcid=@Insert value=/ /a a jwcid=@DirectLink listener=listener:onEnd span jwcid=@Insert value=/ /a /td /tr /table /span span jwcid=[EMAIL PROTECTED] table width=100% tr span jwcid=[EMAIL PROTECTED] source=ognl:collection value=ognl:currentObject index=ognl:index span jwcid=@If condition=ognl:(index % tableSize) == 0 span jwcid=@Insert value=/trtr raw=true/ /span td a jwcid=[EMAIL PROTECTED] listener=listener:edit parameters=ognl:currentObject img jwcid=@Image image=ognl:photoAsset alt=ognl:currentObject.demographics.city title=ognl:currentObject.demographics.city width=160 height=110 / /a /td /span /tr /table /span form jwcid=[EMAIL PROTECTED] listener=listener:onFormSubmit div jwcid=@RenderBlock block=ognl:components.autoPagingContent/ div jwcid=@RenderBlock block=ognl:components.collectionContent/ div jwcid=@RenderBlock block=ognl:components.autoPagingContent/ /form Help yourself to FREE treats served up daily at the Messenger Café. Stop by today! _ Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare! http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews
propertyselection not cached
Folks, I have a propertyselection component rigged with 1,2,3,4,5... Everytime I select from my propertyselection... the this.form.submit() listener gets called... but my property gets reset. Nothing sticks... Gallery.JAVA public IPage onFormSubmit (IRequestCycle cycle) { IPage page = cycle.getPage(); return page; } Any ideas? My rendering is fine...Template follows: Best regards Ken in nashua span jwcid=$content$ span jwcid=[EMAIL PROTECTED] table width=100% border=1 tr td width=25% align=left NOWRAP span jwcid=@Insert value=Table Size/ select jwcid=@PropertySelection model=ognl:@[EMAIL PROTECTED] value=ognl:tableSize onchange=javascript:this.form.submit();/select span jwcid=@Insert value=Paging Span/ select jwcid=@PropertySelection model=ognl:@[EMAIL PROTECTED] value=ognl:pagingSpan onchange=javascript:this.form.submit();/select /td td align=left NOWRAP a jwcid=@DirectLink listener=listener:onBegin style=fontSize:15px; span jwcid=@Insert value=/ /a a jwcid=@DirectLink listener=listener:onPrev span jwcid=@Insert value=/ /a a jwcid=@DirectLink listener=listener:onPage parameters=ognl:1 span jwcid=@Insert value=ognl:1/ /a a jwcid=@DirectLink listener=listener:onPage parameters=ognl:2 span jwcid=@Insert value=ognl:2/ /a a jwcid=@DirectLink listener=listener:onPage parameters=ognl:3 span jwcid=@Insert value=ognl:3/ /a a jwcid=@DirectLink listener=listener:onPage parameters=ognl:4 span jwcid=@Insert value=ognl:4/ /a a jwcid=@DirectLink listener=listener:onPage parameters=ognl:5 span jwcid=@Insert value=ognl:5/ /a a jwcid=@DirectLink listener=listener:onNext span jwcid=@Insert value=/ /a a jwcid=@DirectLink listener=listener:onEnd span jwcid=@Insert value=/ /a /td /tr /table /span span jwcid=[EMAIL PROTECTED] table width=100% tr span jwcid=[EMAIL PROTECTED] source=ognl:collection value=ognl:currentObject index=ognl:index span jwcid=@If condition=ognl:(index % tableSize) == 0 span jwcid=@Insert value=/trtr raw=true/ /span td a jwcid=[EMAIL PROTECTED] listener=listener:edit parameters=ognl:currentObject img jwcid=@Image image=ognl:photoAsset alt=ognl:currentObject.demographics.city title=ognl:currentObject.demographics.city width=160 height=110 / /a /td /span /tr /table /span form jwcid=[EMAIL PROTECTED] listener=listener:onFormSubmit div jwcid=@RenderBlock block=ognl:components.autoPagingContent/ div jwcid=@RenderBlock block=ognl:components.collectionContent/ div jwcid=@RenderBlock block=ognl:components.autoPagingContent/ /form _ Help yourself to FREE treats served up daily at the Messenger Café. Stop by today. http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline
RE: propertyselection not cached
I'm assuming this is related to your later post: is not bound and can not be updated or BINDINGEXCEPTION ? Play it safe and choose names for the persistent page parameters for your select values that are different from the parameters used for components on the page - at least until you can understand what's happening. Then wire the component parameter to the persistent page property. I've hit odd stuff before when I've had the same page property name as component parameter name. Jon -Original Message- From: Ken nashua [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 09, 2007 3:48 PM To: users@tapestry.apache.org Subject: propertyselection not cached Folks, I have a propertyselection component rigged with 1,2,3,4,5... Everytime I select from my propertyselection... the this.form.submit() listener gets called... but my property gets reset. Nothing sticks... Gallery.JAVA public IPage onFormSubmit (IRequestCycle cycle) { IPage page = cycle.getPage(); return page; } Any ideas? My rendering is fine...Template follows: Best regards Ken in nashua span jwcid=$content$ span jwcid=[EMAIL PROTECTED] table width=100% border=1 tr td width=25% align=left NOWRAP span jwcid=@Insert value=Table Size/ select jwcid=@PropertySelection model=ognl:@[EMAIL PROTECTED] value=ognl:tableSize onchange=javascript:this.form.submit();/select span jwcid=@Insert value=Paging Span/ select jwcid=@PropertySelection model=ognl:@[EMAIL PROTECTED] value=ognl:pagingSpan onchange=javascript:this.form.submit();/select /td td align=left NOWRAP a jwcid=@DirectLink listener=listener:onBegin style=fontSize:15px; span jwcid=@Insert value=/ /a a jwcid=@DirectLink listener=listener:onPrev span jwcid=@Insert value=/ /a a jwcid=@DirectLink listener=listener:onPage parameters=ognl:1 span jwcid=@Insert value=ognl:1/ /a a jwcid=@DirectLink listener=listener:onPage parameters=ognl:2 span jwcid=@Insert value=ognl:2/ /a a jwcid=@DirectLink listener=listener:onPage parameters=ognl:3 span jwcid=@Insert value=ognl:3/ /a a jwcid=@DirectLink listener=listener:onPage parameters=ognl:4 span jwcid=@Insert value=ognl:4/ /a a jwcid=@DirectLink listener=listener:onPage parameters=ognl:5 span jwcid=@Insert value=ognl:5/ /a a jwcid=@DirectLink listener=listener:onNext span jwcid=@Insert value=/ /a a jwcid=@DirectLink listener=listener:onEnd span jwcid=@Insert value=/ /a /td /tr /table /span span jwcid=[EMAIL PROTECTED] table width=100% tr span jwcid=[EMAIL PROTECTED] source=ognl:collection value=ognl:currentObject index=ognl:index span jwcid=@If condition=ognl:(index % tableSize) == 0 span jwcid=@Insert value=/trtr raw=true/ /span td a jwcid=[EMAIL PROTECTED] listener=listener:edit parameters=ognl:currentObject img jwcid=@Image image=ognl:photoAsset alt=ognl:currentObject.demographics.city title=ognl:currentObject.demographics.city width=160 height=110 / /a /td /span /tr /table /span form jwcid=[EMAIL PROTECTED] listener=listener:onFormSubmit div jwcid=@RenderBlock block=ognl:components.autoPagingContent/ div jwcid=@RenderBlock block=ognl:components.collectionContent/ div jwcid=@RenderBlock block=ognl:components.autoPagingContent/ /form _ Help yourself to FREE treats served up daily at the Messenger Café. Stop by today. http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_Oct WLtagline - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dojo error on Yahoo search or Live search cached pages
Christian Dutaret wrote: Should I file a JIRA issue for this? Go ahead... did you get to the source of it? 2007/2/1, andyhot [EMAIL PROTECTED]: Yea, you're right. Just did a yahoo search for opencomponentry demo and the first result (the tacos demo) has the same issue... http://216.109.125.130/search/cache?p=opencomponentry+demoei=UTF-8fr=yfp-t-501x=wrtu=opencomponentry.com:8080/tacos/appw=opencomponentry+demod=Tt4hHexsOKoEicp=1.intl=us Same thing happens (for that page) on the google cache as well. http://216.239.59.104/search?q=cache:hENlXPtmM3UJ:opencomponentry.com:8080/tacos/+opencomponentry+demohl=engl=grct=clnkcd=1client=firefox-a We'll need to do some js debugging to figure out this... Christian Dutaret wrote: Hi all, I deployed a brand new web site which is based on T4.1.1 last week. It has just began to be indexed on Yahoo search and Live search. On both these search engines, whenever I request the cached page from the search results, an alert box tells me Permission refused to obtain the Window.dojo property (freely translated from French actually). I understand that the search engine cache is trying to execute some remote js on my page, which it is not allowed to, but is there any workaround to this? I don't know about google's cache behavior, since we're not yet indexed on google (thanks to the #$@§#§!£ google sandbox). Thx for any hint Ch. -- Andreas Andreou - [EMAIL PROTECTED] - http://andyhot.di.uoa.gr Tapestry / Tacos developer Open Source / J2EE Consulting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andreas Andreou - [EMAIL PROTECTED] - http://andyhot.di.uoa.gr Tapestry / Tacos developer Open Source / J2EE Consulting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Dojo error on Yahoo search or Live search cached pages
Hi all, I deployed a brand new web site which is based on T4.1.1 last week. It has just began to be indexed on Yahoo search and Live search. On both these search engines, whenever I request the cached page from the search results, an alert box tells me Permission refused to obtain the Window.dojo property (freely translated from French actually). I understand that the search engine cache is trying to execute some remote js on my page, which it is not allowed to, but is there any workaround to this? I don't know about google's cache behavior, since we're not yet indexed on google (thanks to the #$@§#§!£ google sandbox). Thx for any hint Ch.
Re: Dojo error on Yahoo search or Live search cached pages
Yea, you're right. Just did a yahoo search for opencomponentry demo and the first result (the tacos demo) has the same issue... http://216.109.125.130/search/cache?p=opencomponentry+demoei=UTF-8fr=yfp-t-501x=wrtu=opencomponentry.com:8080/tacos/appw=opencomponentry+demod=Tt4hHexsOKoEicp=1.intl=us Same thing happens (for that page) on the google cache as well. http://216.239.59.104/search?q=cache:hENlXPtmM3UJ:opencomponentry.com:8080/tacos/+opencomponentry+demohl=engl=grct=clnkcd=1client=firefox-a We'll need to do some js debugging to figure out this... Christian Dutaret wrote: Hi all, I deployed a brand new web site which is based on T4.1.1 last week. It has just began to be indexed on Yahoo search and Live search. On both these search engines, whenever I request the cached page from the search results, an alert box tells me Permission refused to obtain the Window.dojo property (freely translated from French actually). I understand that the search engine cache is trying to execute some remote js on my page, which it is not allowed to, but is there any workaround to this? I don't know about google's cache behavior, since we're not yet indexed on google (thanks to the #$@§#§!£ google sandbox). Thx for any hint Ch. -- Andreas Andreou - [EMAIL PROTECTED] - http://andyhot.di.uoa.gr Tapestry / Tacos developer Open Source / J2EE Consulting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Parameter values are cached?
Have you looked at the source for the For component? If that can do it, you should be able to with your While. -- Kevin On Tue, 20 Jun 2006 14:15:08 -0400, Dan Adams [EMAIL PROTECTED] wrote: I want to write a @While component that takes a condition just like @If does. The problem is that you can't give an ognl expression for the condition and have it evaluated each time I call getCondition(). Anyone know a way to do this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Parameter values are cached?
It was a dumb question on my part. I should have replied when I saw it. @Parameter has a 'cache' parameter. duh. :) On Tue, 2006-06-20 at 14:30 -0400, Kevin Menard wrote: Have you looked at the source for the For component? If that can do it, you should be able to with your While. -- Dan Adams Software Engineer Interactive Factory 617.235.5857 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]