I think it's possible, but there are something to care about:

- Do those site have same content types? same catalogs?

- How you handler users? sessions?

- How do you handle orders?

- How about performance? The commerce database is quite heavily loaded with transactions.

I think the easier way is to have two separated sites, and set up so they listen to each other - via RemoteEventServiceEndPoint and RemoteEventServiceClientEndPoint, then you can create your own implementation of CatalogEventListenerBase to sync catalog contents.

Regards.

/Q

Yes the sites will share same templates. 

one of the sites will be read only state, only for viewing products and yes they will share same catalogs

will be no users

orders will be handled on one site only

well, the perfomrance im not sure.. will this be a issue? 

so your suggestion is to have 2 separate sites and 2 separate commerce databases not to be shared with eachother? 

then set up a sync to sync them together and not have them share same commerce db? 

From your information I think it's possible to share the database. Just set up the remote events properly for the cache - it should be fine. It might be easier to implement if you consider the relationship is master-slave, when the master is the normal, full functioning site and the slave only fresh cache from the events get from master site.

Regards.

/Q

actuallt the sites will only have to share same catalogs

they will have their own CMS content that i dont want to be replicated between them, will this work for only catalog content (all the products)? 

we have to be able to update products from both sites so i guess both should be subscriber and publisher right?

If you implement CatalogEventListenerBase it would only handle the catalog contents. But if you want to update from both sites then you might want to care about race conditions.

/Q