Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 7080 invoked from network); 12 Sep 2004 10:02:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 12 Sep 2004 10:02:21 -0000 Received: (qmail 70002 invoked by uid 500); 12 Sep 2004 10:02:15 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 69849 invoked by uid 500); 12 Sep 2004 10:02:11 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 69834 invoked by uid 99); 12 Sep 2004 10:02:11 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from [130.149.66.116] (HELO vern.chem.tu-berlin.de) (130.149.66.116) by apache.org (qpsmtpd/0.28) with ESMTP; Sun, 12 Sep 2004 03:02:09 -0700 Received: from vern.chem.tu-berlin.de (localhost [127.0.0.1]) by vern.chem.tu-berlin.de (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id i8CA25gL020876 for ; Sun, 12 Sep 2004 12:02:05 +0200 Received: from localhost (stephan@localhost) by vern.chem.tu-berlin.de (8.12.3/8.12.3/Submit) with ESMTP id i8CA24SE020873 for ; Sun, 12 Sep 2004 12:02:05 +0200 X-Authentication-Warning: vern.chem.tu-berlin.de: stephan owned process doing -bs Date: Sun, 12 Sep 2004 12:02:04 +0200 (CEST) From: Stephan Michels X-X-Sender: stephan@vern.chem.tu-berlin.de To: dev@cocoon.apache.org Subject: Re: How to Implement a Javaflow Application properly In-Reply-To: <20040911104943.GA1215@nikratio.uucp.uni-x.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On Sat, 11 Sep 2004, Nikolaus Rath wrote: > I suspect that Cocoon uses some sort of Serialization to implement > Continuations and that the size and amount of referenced objects > directly influences performance. The JavaFlow stores the Continuable objects in the session, so that the field have the scope of the session. On the other side the local variables are stored into the continuation, managed by the ContinuationManager . > Therefore I'm playing with the idea to store the application data in an > external database and to access it using JDBC. > > To put it into a nutshell, my questions are: > * How do continuations work in general and what should I consider > when using them? The continuation stores the execution state of a function/method invocation. Nothing more or less. > * Is it sensible to use an external database instead of keeping the > data in-memory? How do you do it in your normal webapp? > * How can my java flow handler retrieve a component manager? It would > be nice if I can use pooled connections. Yes, you can use the inherited method getComponent() from AbstractContinuable > * Will my db connection persist a continuation? ?? What? You mean if your continuation persist the db connnect?! Hmm, I'm not an expert, but I would prefer a separate component to manage the db interaction. > * What will happen with other threads when one thread calls > sendPageAndWait? Nothing, I think. The contination manager uses thread locals to the keep track of the used thread. > PS: The Flow feature in cocoon is one of the most exciting ideas I've > ever seen. Really great work - Thanks for all your efforts! Thanks.