Inline ... > > 1. the Session doesn't need to be tightly bound. unlike EOEditingContext >> that's tightly bound to the EOObjectStoreCoordinator >> > I'm not exactly sure what you mean here, or what you the desired features > would be if you could "unbind" an EC from an OSC? You can obviously just > make an EC with a new instance of an OSC and have it standalone, but I'd be > curious to hear more about what kinds of problems you're trying to solve.
For request-response loop 1, I could have Session bound to DB connection 1, and for request-response loop 2 I could have the same Session bound to DB Connection 2. As I understand EOEditingContexts are bound to an OSC. So all the ECs for one OSC would contend for the same DB connection and it would be harder to scale out? > > > 2. it's easier to multi-thread and connection pool with Hibernate >> > I'm not sure this is NECESSARILY true ... I suppose it depends on how you > look at it, but for instance, > http://blog.xebia.com/2009/02/07/hibernate-and-multi-threading/ basically > shows that Hibernate has some of the same threading complexities that EOF > does with respect to sharing objects between threads, at which point, you're > really probably comparing using multiple OSC's. I will definitely grant that > EOF's snapshot cache is both a blessing an a curse. I believe hibernate has > a "snapshot cache" (equivalent) as well, but that the default behavior is > that the cache goes away when the session goes away (which is typically > session-per-request in Hibernate as I understand it?), so there are much > fewer issues with cache freshness in exchange for default behavior that hits > the db more often. You can add a second level cache to Hibernate, at which > point, I imagine the issues are identical (cache invalidation is cache > invalidation -- no way around it really). Hibernate is written with much > better abstractions here, though, in that you can rip out the backing layers > and change their behavior -- this is very hard to do in EOF, though > something that will hopefully be changed. I think one of the issues with > WO/EOF is that it's easy to do some really complicated things, but actually > kind of hard to do some easy things ... If you WANT to make an app that has > the behavioral characteristics of, say, Rails w/ routers and controllers + > EOF that behaves more like Hibernate or ActiveRecord, you really have to > work at it. I'd like to see some more support for alternative use cases -- I > sometimes feel like I'm fighting EOF to do something that shouldn't be hard. Kind of similar to #1 above. It's easier to just take a free connection from a DB connection pool. In essence a Hibernate session directly binds to a DB connection and doesn't have an OSC layer in between. Yes, Hibernate has the same multi-threading challenges that EOF does, [like the Session is not thread-safe]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
