you can get a good connection pooling class from
http://www.javaexchange.com/ this is class only , no source. Also have a
look a the Java Servlet Programming book. Jason hunter wrote one
www.servlets.com
This book is outdated now and only covers servlet 2.0 but is still a good
book.
Finally JDBC 2.0 supports the Datastore interface. And with J2EE this is
supposed to be implemented to provide transparent db pooling. All J2EE app
servers should support it, you get it through it's JNDI name :)
-----Original Message-----
From: Suryanarayana Murthy [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 31, 2000 8:15 AM
To: [EMAIL PROTECTED]
Subject: Re: EJB's vs Servlets
Could you please send me the connectionpoolin class code to me? Actually I
have written one class.but I want to know any other methods. Is there any
PoolConnection class provided by either sun or Oracle? I think in JDBC, I
saw a similar class.
Please help me out.
Murthy
> -----Original Message-----
> From: yadam laxminarayana [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, May 30, 2000 2:41 PM
> To: [EMAIL PROTECTED]
> Subject: Re: EJB's vs Servlets
>
> Hi,
>
> Well, I think we've done a sort of similar project,
> and I would just like to discuss the strategy we've
> adopted. I am not sure whether it is really efficient
> or not, but it works..
>
> I've used JSP pages as the view, Java Beans to
> encapsulate the business logic, and the database was
> MySQL.
>
> Whenever a User logs in, a fresh Bean is created for
> him. This would remain in the server as long as that
> session is active. This bean maintains the state of
> the User throughout. The advantage of this approach
> is that it gives us the flexibility of future
> scalability, without in any way disturbing the view
> and the underlying database.
>
> So, each User Bean is at Session scope. There is one
> bean at Application level, which stores the references
> to all the active User BEans. This enables us to
> cross check, whenever a user tries to log in , whether
> he is already active or not. If yes, access is not
> allowed, thereby preventing the logging of user twice.
> When any session ends, the reference is nullified and
> the Bean is destroyed.
>
> Another application level Object, in which the
> Connection Pooling is implemented, is available for
> all the User Beans. All the User Beans get a free
> Connection returned by a method in this Object,
> execute the query and fetch the resultset and return
> back the connection.
>
> I've implemented my own Connection Pooling class and
> also a third party ConnectionBroker class. Both are
> working perfectly fine.
>
> Pls tell me the disadvantages, if u suspect, in the
> above design.
>
> Y.Laxminarayana
>
>
>
> --- Rishi Shehrawat <[EMAIL PROTECTED]>
> wrote:
>
> <HR>
> <html><DIV id=cdiv>
> <P>Hi, <BR><BR>I know probably this has been discussed
> on the forum before, i tried finding out some answers
> to my question but was unable to do so. <BR><BR>I will
> try explaining the problem <BR>We are in the process
> developing a portal for a client. <BR>This is
> basically a search based site with absolutely no
> transactions although they might be added later when
> the site is e-commerce enabled. <BR>There are no dbase
> updates <BR>There are different categories, &
> sub-categories & surfers can get search results
> based on the search criteria given by them. <BR>There
> is a generic keyword search & a
> category/sub-category specific search where a a surfer
> can get the results based on the narrowing options for
> the specific category/sub-category. <BR>The client
> will most probably be using IBM Websphere application
> server & NES web server. <BR>Time taken to process
> a client request is very important <BR><BR><BR>The
> different options availiable to us are (to the best of
> m!
> y knowledge): <BR>Entity Beans <BR>Stateful &
> stateless Session Beans <BR>Servlets/JSP's <BR><BR>I
> think entity beans are out as there are no
> transactions & security issues. They would take up
> a lot of resources. I was also thinking that stateful
> session beans would not be a very good idea. I think
> it would be best to perform the search & keep the
> results as a session object instead of having a
> stateful session to service the request. Now we are
> left with stateless session beans & servlets.
> <BR><BR>The stateless beans will have the SQL
> statements. From what i have read a few stateless
> session bean beans can request a lot of clients. As
> mentioned in the Gemstone Developer's guide a pool of
> instances can be maintained at the client servlet so
> that i can save the lookup & create time .Also the
> database connection pooling will again help in cutting
> down on the processing time. Plus the other advantages
> of the application server. Caching of results is
> another !
> option but i am not very sure if it will work in our
> case as there are different queries for different
> categories, a single cache cannot sevice the requests
> & there are a large number of the
> categories\sub-categories to write a cache specefic to
> each category. <BR>The immediate downside i could
> think up of was the network traffic between the web
> server & the application server. <BR><BR>In case
> of a servlet i would directly fire a SQL get the
> results from the dbase & service the clients
> request. I bypass the app server. <BR>The problem i
> see here is the load handling capabilities of the web
> server. The web server might not provide facilities
> like connection pooling.The presentation layer will be
> tightly coupled with the business logic. I could
> probably overcome this by using java objects.. But
> this could again slow down the system... <BR><BR>So as
> you can see i am quite confused on which would be a
> better approach. I feel that SSB's might be a better
> approach, but!
> again i am not very sure !!! Please let me know your
> experiences. Which approach do you think is best
> suited for the requiements mentioned above.
> <BR><BR>Thanks In Advance <BR>Rishi
> <BR></P></DIV><p><hr>Get Your Private, Free E-mail
> from MSN Hotmail at <a
> href="http://www.hotmail.com/">http://www.hotmail.com</a><br></html>
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED]
> and include in the body
> of the message "signoff EJB-INTEREST". For general
> help, send email to
> [EMAIL PROTECTED] and include in the body of the
> message "help".
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Kick off your party with Yahoo! Invites.
> http://invites.yahoo.com/
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
