Hi everyone,
Has anyone used JAVAMAIL in your applications, if so ,please confirm me so
that I explain my problem clearly.
Thanks,
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".
