[elephant-devel] Advice on multiple deploying multiple applications/repositories

[Ian Eslick]

JD,

Probably not the right forum for a detailed discussion of this,  
although many Elephant users do deploy it in a web application  
environment.  I currently use Weblocks for a significant application  
and can say that it still has some significant warts, particularly in  
the navigation model it has committed to.  I think UCW is more mature,  
but perhaps less active.

Another option to look at is the core server project yet, although it  
is integrated with a different persistent store model.

Ian

On Feb 6, 2009, at 6:16 PM, John wrote:

> Thanks for the prompt response. We hadn't actually looked at any web  
> frameworks per se. Our intention is not to develop our own. Instead  
> have read up a little on weblocks, ucw, kpax, kanamit, and  
> hunchentoot.
>
> Our goal is to set up two different layers on Lisp code (maybe  
> different machines for each layer). The lower layer will be a Lisp  
> image offering a web-service-like API to the middle-layer. The  
> middle-layer will contain the actual web framework that will  
> interact with Apache and the lower layer. I suppose the lower layer  
> could work with something as "simple" as hunchentoot and both layers  
> will communicate via internal HTTP. The middle layer will have the  
> business-front logic and presentation code and this is where we  
> liked weblocks for. We also liked ucw but feel weblocks seems to  
> have a more active community.
>
> I guess we could just as well use weblocks for the lower layer, but  
> that may just be too much for what's really needed off it.
>
> I could ask which you would recommend but that probably doesn't  
> belong in this list and it also probably depends on the actual goal  
> and design of the application. It may sound as if this whole setup  
> seems like an overkill for such simple application, but the  
> applications I mentioned were just mere examples. Our intention is  
> to develop much more "mission-critical" applications... but we still  
> have a lot to learn.
>
> So, assuming we're only concentrating on the lower-layer, I think  
> the recommendation to dynamically bind *store-controller* for each  
> request/thread depending on the app may sound like the best approach.
>
> Your other suggestion of deploying them on multiple machines is very  
> valid. The only reason we don't consider that is strictly cost  
> reasons. I know you can get a shared hosting account where you can  
> install Lisp for about $9/month, but our corporate requirements for  
> IT systems require us to use much more expensive environments, and  
> so we are trying to re-use as much as possible the resources given.
>
> Thanks again,
> JD
>
> On Fri, Feb 6, 2009 at 5:08 PM, Ian Eslick <eslick at media.mit.edu>  
> wrote:
> The answer to this depends on the web framework you are using.
>
> A simple answer is to dynamically bind *store-controller* for each app
> for each request/thread.  Since each thread will have its own binding,
> each is tied to a particular application.
>
> If you put all your database IO into a with-transaction body you can
> use the :store-controller argument to pass in the current store which
> will then be bound to *store-controller* in the body of the with-
> transaction form.
>
> If you use a higher level web framework like weblocks, it already
> directs through its own store abstraction and supports multiple
> webapps, each with a different store which will then handle all the
> *store-controller* stuff for you if you don't violate the abstraction
> (which you will probably want to do, however).
>
> If you are rolling your own web framework, then I'd just implement
> abstractions around the database operations which know what app is
> running and directly supplies the appropriate store-controller to the
> functions requiring/supporting :sc or :store-controller arguments.
>
> However, if each of your apps is that independent, why not just put
> one per server and avoid the complexity?
>
> Ian
>
> On Feb 6, 2009, at 4:31 PM, John wrote:
>
> > Since our interest is to use Lisp and Elephant to create web
> > applications, I'd like to request some deployment advise for Lisp
> > and/or Elephant.
> >
> > Our intention is to have Apache in front of a Lisp image running
> > some web server, where Apache will simply allow us to proxy/load-
> > balance traffic. Maybe we could have Lisp running in a large machine
> > "fronted" by multiple Apache servers.
> >
> > Imagine we want to offer to separate services. One would allow
> > people to maintain a list of friends and contacts (AKA a contact
> > database) and the other will allow people to maintain a To-Do List.
> >
> > We thought we could have a single Lisp instance listen for requests
> > based on URL or entry points. Each application would have its own
> > data store. By default, Elephant functions use *store-controller* to
> > connect to the data store. However, since we'll have multiple data
> > stores, the question is: should we be rebinding *store-controller*
> > for each application, pass a specific :sc argument to all our
> > function calls, or simply have multiple Lisp instances running and
> > listening on different ports for each application?
> >
> > I thought we could just have a single Lisp instance for all the
> > applications we wanted to deploy, but am confused as to how a single
> > Elephant instance could handle multiple stores, one for each
> > application, or better yet, what would be the most advisable
> > deployment model for something like this.
> >
> > Thanks in advanced,
> > JD
> > _______________________________________________
> > elephant-devel site list
> > elephant-devel at common-lisp.net
> > http://common-lisp.net/mailman/listinfo/elephant-devel
>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel