Thank you all for the explanations. For several of the projects I've already done, this hasn't been an issue and I find the development environment easy to understand (once I passed that first learning curve) and as Samuel said, efficient. I can get something up and running very, very quickly. The next app, I'm hoping to be larger and more social network like (who doesn't :-)) and I think I may do some more investigations. Prototype might be done with WO since I'm already a bit done, but may investigate a rewrite in something that favors an app with something like 90-95% reads. May still be able to get away with it since I've got plans for an HTTP caching tier that may help.
Tarun On Tue, Jun 7, 2016 at 7:44 AM, Samuel Pelletier <sam...@samkar.com> wrote: > This is a situation where there is a cost for a huge benefit. Like > everything, there is a trade-off and you need to understand your needs. > > If you write an app to do reporting with potentially very long fetches of > thousands of rows, EOF is not the best tool out there. If this is only for > few users for a complex system with big business rules, you can achieve > good result by using an OSC per user. > > EOF maintains a very efficient object cache and propagate changes > automatically (this is unique unless Cayenne does it now) and for mostly > interactive apps where many peoples manage a shared set of data, there is > nothing else matching it's efficiency I know. A single instance app can > easily handle at least an hundred of concurrent users if well written and > traverse the object graph instead of fetching. Fetch is the keyword to > avoid when using EOF. > > My average transaction time is usually bellow 0.05 second, I would > consider an average response time of 0.1 second to be a big alert. > > Anyway, people tend to forget that any change to database will be > serialized by the database server (per table) and an interactive app always > save changes. My apps have probably around 30-40% of request doing saves... > > If you are building a social network app where there is 99% of reads, and > huge data volumes and gazillions of concurrent users, EOF is not the best > tool. Anyway, these app tend to have much simpler business rules and a full > fledged ORM is probably overkill anyway. > > There is no universally good tool, many of the possible features or > optimizations are simply not compatible. If a tool is wonderful for a type > of solution, it will be bad for another. > > For my current type of development, Wonder with EOF is very efficient and > a perfect fit but I do not think it is true for all possible projects. > > Samuel > > > Le 6 juin 2016 à 19:21, Tarun Reddy <t...@cornell.edu> a écrit : > > Huh. Never knew this (serial DB access). Is there a recommended way of > scaling out a WebObjects/Wonder application that doesn’t involve many, many > JVMs? Or should I really be using another application framework? > > Tarun > > > > On Jun 6, 2016, at 11:48 AM, Chuck Hill <ch...@gevityinc.com> wrote: > > I am pretty sure that maps to the ServerSocket’s backlog: “requested > maximum length of the queue of incoming connections” > > > *From: *<webobjects-dev-bounces+chill=gevityinc....@lists.apple.com> on > behalf of Ramsey Gurley <rgur...@smarthealth.com> > *Date: *Monday, June 6, 2016 at 10:44 AM > *To: *Leigh Kivenko <lei...@portfolioaid.com> > *Cc: *WebObjects-Dev <webobjects-dev@lists.apple.com> > *Subject: *Re: Question about jdbc connection pool > > Off the top of my head, not sure. It’s probably specified in java monitor > help. But it has nothing to do with database connections AFAIK. > > On Jun 6, 2016, at 10:31 AM, Leigh Kivenko <lei...@portfolioaid.com> > wrote: > > > Thanks again. What is the “Connection pool size” in the JavaMonitor then? > Something else? > > <image001.jpg> > > > *Leigh Kivenko* | VP, Technology > *PortfolioAid* > > *t**.* 416-479-0523 | *e**.* lei...@portfolioaid.com > > This e-mail may be privileged and confidential. If you received this > e-mail in error, please do not use, copy or distribute it, but advise me > immediately (by return e-mail or otherwise), and delete the e-mail. > > *From:* Ramsey Gurley [mailto:rgur...@smarthealth.com > <rgur...@smarthealth.com>] > *Sent:* Monday, June 06, 2016 12:52 PM > *To:* Leigh Kivenko <lei...@portfolioaid.com> > *Cc:* webobjects-dev@lists.apple.com > *Subject:* Re: Question about jdbc connection pool > > Yes, one connection per application instance is the default. > > On Jun 6, 2016, at 9:47 AM, Leigh Kivenko <lei...@portfolioaid.com> wrote: > > > > Thanks Ramsey. Does that mean there is only 1 database connection shared > by all end-users of an app? So if a user hits a query that runs for 3+ > seconds all other application users are stuck waiting for that query to > complete? > > > *Leigh Kivenko* | VP, Technology > *PortfolioAid* > > *t**.* 416-479-0523 | *e**.* lei...@portfolioaid.com > > This e-mail may be privileged and confidential. If you received this > e-mail in error, please do not use, copy or distribute it, but advise me > immediately (by return e-mail or otherwise), and delete the e-mail. > > *From:* webobjects-dev-bounces+dev=portfolioaid....@lists.apple.com [ > mailto:webobjects-dev-bounces+dev=portfolioaid....@lists.apple.com > <webobjects-dev-bounces+dev=portfolioaid....@lists.apple.com>] *On Behalf > Of *Ramsey Gurley > *Sent:* Monday, June 06, 2016 12:18 PM > *To:* Leigh Kivenko <lei...@portfolioaid.com> > *Cc:* webobjects-dev@lists.apple.com > *Subject:* Re: Question about jdbc connection pool > > The ObjectStoreCoordinator opens one connection which everything shares by > default. If you want multiple connections, you have to create multiple > OSCs. There’s an OSC pool built into Wonder, but it leaks memory. > > On Jun 6, 2016, at 8:40 AM, Leigh Kivenko <lei...@portfolioaid.com> wrote: > > > > > Hello, > How does one set the jdbc connection pool size? Is there a default if this > isn’t specifically set? > > Thanks, > > > *Leigh Kivenko* | VP, Technology > *PortfolioAid* > > *t**.* 416-479-0523 | *e**.* lei...@portfolioaid.com > > This e-mail may be privileged and confidential. If you received this > e-mail in error, please do not use, copy or distribute it, but advise me > immediately (by return e-mail or otherwise), and delete the e-mail. > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > > https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com > > This email sent to rgur...@smarthealth.com > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/tvr1%40cornell.edu > > This email sent to t...@cornell.edu > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com > > This email sent to sam...@samkar.com > > >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
