> > Depending on what you want from castor, it may or may not be a good idea. > > in our case, we found problems in the areas of it we wanted, and there was > > concern in our team over the reliability of it. I would also be considering > > This scares me, where did you find problems?
inheritence. here's one of the posts to castor-dev: http://www.mail-archive.com/[email protected]/msg03410.html if you do a search for other posts by Victor, you should get a fair rundown of the issue(s) we had. I personally wasn't looking at it, so cant speak of it too deeply, but essentially the problem was to do with the way castor handles inheritence - say you have your Emplyoee base class, and then have Developer, Manager, etc. etc. (model may not be perfect - but for the example). Castor basically requires Employee to be an object in itself, and have its own table. The Developer table then has the same pk columns, and corresponding values etc... this is all from memory, so comes with a big disclaimer (o: now the problem we faced came when we tried to query all developers with abc... problem was that if castor already had object x cached as an employee, when really its a developer, the developer query would throw the equivalent of a classcast exception when trying to return results, because the cache gives an employee when it wants a developer... thats probably a pretty messy way of explaining it - if Victor is still on this list, he might go into it more for you, but I hope you get the drift. > > entity beans - the main reason we looked at castor was the shared access on > > query results, so I could have two "findAll" methods running, and if > > I plan on using Castor only for the DAO classes (per the J2EE pattern). > I'd like to: > > A) Not write JDBC > B) Take advantage of shared access on query results like you mentioned. > > This means I *will* be using EJB. I'm just wondering if replacing the > innards of DAO classes (or replacing them altogether) with JDO calls > instead of JDBC calls is a smart idea on two fronts: using bmp entity beans? and doing the persistence through castor? I'm a little confused now... > A) System design flaws this might introduce. > B) Quality of Castor when utilized in this fashion. (I don't quite > understand all the transaction and context stuff involved in EJB's yet). tx and security in ejbs can be done to a certain extent in deployment descriptors, so I can say that every call to this ejb _must_ be in a new tx, or will join an existing tx if there is already one going, and so on. security is similar - this role can call this method, blah blah blah... still doesn't give you ownership of entities though, or state based security. > > were both read only, there would be no lockouts. This to me is the biggest > > disadvantage of entity beans as they currently stand, I for one dont see why > > the container doesn't provide a read-only equivalent of the finder > > method.... > > I'm not sure I understand this. You want read only calls to lock each > other out? no, thats why I was looking at castor... (o: > Thanks, > -ryan hope its helpful.. cheers dim _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
