I think WO is the best tool but EO is not for everyone.
I would agree with this ... EOF is excellent, but there are aspects that I wish were more configurable. That said, I have never found a problem that I couldn't solve. When I try to find developers for WO other than me,it was difficult or high cost.
People who can select to learn WO or EO is very limited.This is contrast to PHP.
Yes, there are a huge number of PHP developers. If you find a WO/EO person, they are likely to be a lot more expensive (and harder to find in the first place), but if you do, they are likely self-selected to be a much better quality developer on average. We don't hire WO people. We hire good developers and we train them on WO. Honestly this would be true of almost any organization. Most companies use a mix of technologies and you rarely find someone who can just roll in off the street and work on your system. There is always a training investment. So I am afraid that using EO may not be the best solution.
I'm not sure I would necessarily conclude this ... This same argument could equally be made for the "WO" part of WO/EOF, right? (I have a mac but it is not my main machine. so I will never upgrade WO from 5.2) Not sure why you wouldn't go to 5.3, but I suppose you have your reasons. 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.
ms |