• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Multi-tenant Postgres support with EOF ?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Multi-tenant Postgres support with EOF ?


  • Subject: Re: Multi-tenant Postgres support with EOF ?
  • From: Vanek Josef <email@hidden>
  • Date: Fri, 25 Nov 2016 13:16:10 -0500

Thank you very much guys, I really appreciate your feedback and will think about your suggestions.

Josef


Le 25 novembre 2016 à 17:29:20, Samuel Pelletier (email@hidden) a écrit:

Josef,

Personally, I use a single schema and connection to the database with the object representing the current tenant in the session and put all the fetch logic in that class that will add the required filtering qualifier. This way of doing things allow a single instance to easily serve multiple tenant and if there is shared objects they are not duplicated. This way will create a big database with big tables containing all the data for all tenants. The app and deployment setup are much simpler though.

Others uses multiple connections or schema but it require some runtime tweaking of the model. This way seems more adapted to setup with separate instance for each tenant, the model tweaking is done on app startup for the complete life of the app. This way allow multiple instance of the database server and will split the load on multiple app and database instances. I do not see any real advantages of this way if all app instance connect to a single database unless there is other code that may connect directly to the data and there is no way to create filtering views for these needs.

Depending on the number of tenant, the expected size of the data and number of concurrent users a method may be more adapted than the other. If a single is enough, my guess is the first way is enough. My own experience seem to indicate a 2012 Mac mini with a SSD can serve at least 300 concurrent users if the app is properly optimized with small sessions and page caches. I would expect more but never tried.

Regards,

Samuel

Le 25 nov. 2016 à 11:07, Vanek Josef <email@hidden> a écrit :


Hi,

We are developing a large website/REST solution for multiple customers. Ideally every customer shall have access only to their own data through ACLs or other mechanism.

We have been thinking of Postgres' native schema management and use if for a multi-tenant solution. Has anyone implemented a Wonder's EOF extension that would be able 
to handle requests on the same connection but on a different scheme depending on some login configuration?

If anyone has advice about the best practice for multi-tenancy DB architectures with WO that differs from our thoughts above, please respond
There must be some people who have experimented with Wonder and multi-tenancy.

Many thanks,
Josef
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: Multi-tenant Postgres support with EOF ?
      • From: Philippe Rabier <email@hidden>
References: 
 >Multi-tenant Postgres support with EOF ? (From: Vanek Josef <email@hidden>)
 >Re: Multi-tenant Postgres support with EOF ? (From: Samuel Pelletier <email@hidden>)

  • Prev by Date: Re: Multi-tenant Postgres support with EOF ?
  • Next by Date: IBM JDK
  • Previous by thread: Re: Multi-tenant Postgres support with EOF ?
  • Next by thread: Re: Multi-tenant Postgres support with EOF ?
  • Index(es):
    • Date
    • Thread