Hello, This is just a reporting about my approach.
1) I have decided to migrate my EOF projects into a plain generated JDBCEditingContext approach. 2) I picked sql2java not hibernate for replacement. And I could use the output from sql2java as a input for another generator. 3) I will investigate the DB layer enhancement with terracotta. Because my projects require massive realtime data stream. 4) I have suceeded in developing and deploying with intelliJ and projectbuilder without plugins and existing libraries. 5) I think I can continue to develop with WO even after Apple stoped its support.(I don't want to extend its death but want to live with WO.) JDBCEditingContext is very plain and lockable with basic synchronized statements. I hope I can be released from any problems coming from the frameworks. I might think that the single threading of WO may be a result of framework's consistency. I don't want to use it anymore or don't want to manage to use it as multi-threading with sacrificing something. I may have mist-understanding or non-understanding somewhere but I feel contented with my simple approach. Now it works without any problems and with massive scaling out. WO is a mature product. But mature is a before-death from a point of marketing. I don't feel comfortable with extending death but feel comfortable with working out. In the future I may summarize the solution. Thank you. Best regards, Ken > > Don't you think terracotta's approach can enhance WO significantly > > with or without EO? > Without EOF .... possibly. With EOF, it's a very complicated problem > because EOF is single-lock on an object store. The contention point > in most WO apps is going to be your EOF lock, so clustering that lock > is only going to INCREASE contention. The typical WO scaling approach > is multiple instance, though as you see, this presents cache sync > issues (which is why ERJGroups exists). > > > I think Tools of WO and structures are still the best but EO is not > > the best today. > I think it is just different. It's difficult to flat out say it's not > the best. You're pretty much going to be comparing against Hibernate, > I think. Hibernate doesn't do in-memory transactions, which I find to > be incredibly powerful. Hibernate, though, supports a richer caching > system which supports a distributed cache and has some SQL > optimizations that EOF doesn't. It doesn't do snapshot caches in > quite the same way, and most people don't really do multi-request > transactions with Hibernate. I'm not necessarily convinced that a WO > + Hibernate app is a bad idea, just a very different programming > model. You should just be aware of what you're giving up making that > decision. > > > I think EO's approach is delaying to the latest. > > I don't want to use additional mechanism or lock-unlock management > > just to increase instances or multiple requests. > > If Apple don't replace it and I don't have enough time to learn > > wonder I have to replace EO with something. > This is why I use Wonder ... It basically automatically solves most of > these complaints. > > > I think > > 1) Having caches for each instance is not efficient. Sharing cache > > is the best. > This is VERY application-dependent. It makes some aspects of > development easier and some harder. If you have a large amount of > user-specific data, sharing a cache is just a good way to blow out > your cache. If you have very collaborative data, then a central cache > would probably be better. But shared caches aren't free ... The more > people you have using your cache, the more you are going to have to > lock, and if you're not locking, then you have to deal with the > fallout of not having a safe transaction model (unless you're using a > cache that is safely hooking into your overall transaction system and > does something like mvcc). > > > 2) Developers today have to learn many things so learning vendor- > > closed technology is not for everyone. > I would agree with this .. > > > 3) EOF may use String and Hashtable for many internal processes.This > > may slow the app. > I'm not sure what you mean about this one, but maybe you mean as > opposed to storing persistent object state in the fields of the pojo? > I think you'll find that if you profile your app, it's hitting your > database that is slow by a huge margin. Switching from state-in-maps > vs state-in-fields is likely not really near the top of the list. > > So, really I don't think you're wrong, you just have to accept that > there aren't many people doing things like you are talking about > taking on, so you need to weigh that risk. But as long as you're OK > with that, I don't really see any terrible problems waiting for you. > I've considered making a WO + Hibernate app just to try it out, also. > > >
_______________________________________________ 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]
