Re: A reminder of why we're here...
On Sun, 9 Jun 2002 19:34:48 +0100, Greg McCarroll [EMAIL PROTECTED] said: GM I was talking to a TA from Accenture recently about Perl, mod_perl and GM Java and he told me that some java application server (i forgot to ask GM him which) could maintain less JDBC connections than http session GM handling threads and share them between the threads as needed without GM prior knowledge of wheter or not the thread needed to do DB work. Is GM there an equivalent way to do this with mod_perl? To my knowledge, GM which may be wrong, there isn't[1]. I haven't tried myself but it looks that it is possible with SQL Relay (http://www.firstworks.com/sqlrelay.html) -- Ilya Martynov (http://martynov.org/)
Re: A reminder of why we're here...
I was talking to a TA from Accenture recently about Perl, mod_perl and Java and he told me that some java application server (i forgot to ask him which) could maintain less JDBC connections than http session handling threads and share them between the threads as needed without prior knowledge of wheter or not the thread needed to do DB work. Sure, any multi-threaded Java program can do that. It's not as useful as it sounds, unless your program has a lot of threads that don't do any database work. That's not very common. For more on this, see this post: http:[EMAIL PROTECTED] g Is there an equivalent way to do this with mod_perl? With the current mod_perl you should use the recommended reverse proxy architecture to keep requests for non-mod_perl content from tying up database connections. With mod_perl 2, those requests will not invoke a perl interpreter and thus will not tie up a database connection. - Perrin
Re: A reminder of why we're here...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 09 June 2002 7:34 pm, Greg McCarroll wrote: * Perrin Harkins ([EMAIL PROTECTED]) wrote: However, J2EE is mostly used for server-side web development, and that's what I was talking about. There's no need for any distributed object technology there about 99% of the time. This is probably as good a place as anywhere for this conversation ... I was talking to a TA from Accenture recently about Perl, mod_perl and Java and he told me that some java application server (i forgot to ask him which) could maintain less JDBC connections than http session handling threads and share them between the threads as needed without prior knowledge of wheter or not the thread needed to do DB work. Is there an equivalent way to do this with mod_perl? To my knowledge, which may be wrong, there isn't[1]. Apparently it's possible with Sybase (Michael Peppler has done something special to support this under mod_perl, but I don't recall exactly what, and I think he has to use the Sybase CtLib or DbLib directly rather than DBI). The details are somewhere deep in the mod_perl list around about a year ago. - -- :-get a SMart net/:- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9A7AqVBc71ct6OywRAuYKAJoDT1mJ+NoqP2p7ZYsG0/K4+HlGJgCfSByX K6PlTTRXxT9judg9/1l5mNQ= =8Jkg -END PGP SIGNATURE-
Re: A reminder of why we're here...
Matt Sergeant wrote: To reduce costs and fast-track enterprise application design and development, the Java2 Platform, Enterprise Edition (J2EE) technology provides a component- based approach to the design, development, assembly, and deployment of enterprise applications. I don't know who they think they're kidding with that reduce costs business. Commercial J2EE software has the most outageous prices. It's common for companies to spend millions on it just to put up a simple web store. - Perrin
Re: A reminder of why we're here...
[EMAIL PROTECTED] writes: With iplanet shipping free with Solaris 9, and the availability of JBoss, the cost of the app Server software is removed from the equation of 'costs'. Well, given the exorbitant cost of the hardware, it's still in the equation... -- Dave Hodgkinson, Wizard for Hire http://www.davehodgkinson.com Editor-in-chief, The Highway Starhttp://www.thehighwaystar.com Interim Technical Director, Web Architecture Consultant for hire
Re: A reminder of why we're here...
[EMAIL PROTECTED] wrote: With iplanet shipping free with Solaris 9, and the availability of JBoss, the cost of the app Server software is removed from the equation of 'costs'. If you're using the free stuff, you're in the minority. Most companies use WebLogic or WebSphere, with a few using iPlanet and even fewer using Oracle. The company I work for now uses ATG Dynamo, which is priced so high it makes the hardware sound cheap. This is not a complaint about J2EE, but rather about managers who insist on spending millions of dollars rather than using free or low-cost alternatives like JBoss, Resin, and Orion. This attitude seems to be the norm among most big companies using Java. To make this at least slightly relevant to this list, I see Perl's value in these situations as being ease of use, speed of development, quality of support, and source code availability. The price is just gravy. - Perrin
Re: A reminder of why we're here...
To make this at least slightly relevant to this list, I see Perl's value in these situations as being ease of use, speed of development, quality of support, and source code availability. The price is just gravy. Pursuing the 'relevance' a bit... I agree with the speed of development. Perl by far surpasses any language I've worked with in that area and is the biggest reason why a P5EE concept has merit. While I agree that the quality of support is unsurpassed, this is still a huge barrier in the Corps. eye. It see's any piece of code as IP, and that posting some code in order to receive some assistance as a potential threat. In fact one of the reasons why Java gets the nod over Perl is that the class files and the other architectural abstractions of J2EE are seen as IP protections. I have pointed out that through the use of apache Mod-perl modules a similar level of abstraction can be created. This approach seems to be more attractive, but there are still so many other hurdles that it alone cannot get Perl to Enterprise status as an Architecture. Perrin Harkins [EMAIL PROTECTED] 06/06/2002 11:37 AM To: [EMAIL PROTECTED] cc: Matt Sergeant [EMAIL PROTECTED], [EMAIL PROTECTED] Subject:Re: A reminder of why we're here... [EMAIL PROTECTED] wrote: With iplanet shipping free with Solaris 9, and the availability of JBoss, the cost of the app Server software is removed from the equation of 'costs'. If you're using the free stuff, you're in the minority. Most companies use WebLogic or WebSphere, with a few using iPlanet and even fewer using Oracle. The company I work for now uses ATG Dynamo, which is priced so high it makes the hardware sound cheap. This is not a complaint about J2EE, but rather about managers who insist on spending millions of dollars rather than using free or low-cost alternatives like JBoss, Resin, and Orion. This attitude seems to be the norm among most big companies using Java. To make this at least slightly relevant to this list, I see Perl's value in these situations as being ease of use, speed of development, quality of support, and source code availability. The price is just gravy. - Perrin
Re: A reminder of why we're here...
On Thu, Jun 06, 2002 at 10:41:28AM -0400, Perrin Harkins wrote: Matt Sergeant wrote: To reduce costs and fast-track enterprise application design and development, the Java2 Platform, Enterprise Edition (J2EE) technology provides a component- based approach to the design, development, assembly, and deployment of enterprise applications. I don't know who they think they're kidding with that reduce costs business. Commercial J2EE software has the most outageous prices. It's common for companies to spend millions on it just to put up a simple web store. Have you considered the alternatives? Like developing with other development platforms (like CORBA ORBs), or component technologies (COM/COM+/DCOM)? ISTR Netscape was big on making IIOP (lightweight CORBA over the Web) an integrated offering in their servers at one point. The most expensive cost is developer time -- time to develop, deploy and maintain an application. The only other model out there that could be used for enterprise development is the old standby client/server w/desktop app model. And that does cost significantly more in terms of tools, developer time, deployment effort, I don't see the section Matt's quoting as praising J2EE for web development, as much as I see that section touting J2EE as a solution to the COM nightmare. Just $0.02. Z.
Re: A reminder of why we're here...
Adam Turoff wrote: Have you considered the alternatives? Like developing with other development platforms (like CORBA ORBs), or component technologies (COM/COM+/DCOM)? Hey, I'm just trying to bitch about my managers and the vendors they love to pay. However, J2EE is mostly used for server-side web development, and that's what I was talking about. There's no need for any distributed object technology there about 99% of the time. The real alternative is cleanly designed Perl modules leveraging CPAN code. - Perrin
