I would add to hangon's suggestion, you really want to avoid considering forking and threading until you are really sure you need it. You won't know you need it until you set up your app and it runs to slow. Even then there are other methods that would likely be more effective at speeding things up (e.g. mod_perl, better hoster, hardware). We're keen to see evidence of using a 'library' (module) slowing down a cgi app (give us the numbers :-).
Using a relational db (e.g. MySQL) will take care of a lot of your worries - that's what it's for.
Generally, there isn't anything in a typical shopping site that would be considered "a long running process". And, again, you won't know for sure until you've tried it.
Something like CGI::Application with CGI::Simple, CGI::Session, HTML::Template, DBI could well give you the reponse times you want. You will also have something that you and others will find more straightforward to maintain. There are many successful shopping sites that do just this.
CGI::App comes with many plugins that will do most of the tasks you need virtually out of the box, it comes with good docs, tutorials, examples (including shopping) and has its own web site (there are others, but I think CGI::App is a good introduction).
I can't help feeling you're introducing massive complexity when you don't need to. Set the thing up. See how it goes. Identify any bottlenecks and the monks will be pleased to wade in and help. While you're getting 15 orders every 3 days is a good time to try it. :-)
Good luck!
In reply to Re^3: Very new to PERL, want to see if CGI spawn concept is possible and or feasible without major pain
by wfsp
in thread Very new to PERL, want to see if CGI spawn concept is possible and or feasible without major pain
by IrishSteve
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |