Hi Gentlemen, Jay Walters wrote: > Seems like an application requiring a CMP Persistence Manager and EJB > container to execute SQL in a specific order might be asking a bit much to > me... and Bill Burke replied: > You'd have the same type of problems with BMP, wouldn't you? Sorry G's, I still can't see the point here. With BMP simply ejbCreate/Store/Remove is called at the appropriate places, especially ejbStore is called after every business method, isn't it? If not, would someone PLEASE point me to the code that does actually deferring the SQL, I just again spent 2 hours in org.jboss.ejb.** hunting for it. If I'm right, the BMP guy has all control over execution of SQL by simply doing the OO operations in some order (having referential integrity in the back of his head). Besides, is such a thing as RI useless/hindering in the OO world? I don't think so, even the pure OO guru respects integrity by i.e. not changing essential things before he knows for sure, that relatet changes can be done. (Else he would be no guru and should learn a session from the relational boys). And, last but not least, in the EJB context, heavily tied to relational store tier (by practical implementations and at least 'between the lines' of the EJB specs), it would be a shame to leave people without referential integrity, by not allowing them to have it on the store (Database) and not providing it in the next higher level by declaration (the entiy bean level). Again, when the BMP guys have full control, why should EJB Server/ Container developers want to leave the CMP guys in the wet? Note, that I'm not against the push() thing just published on top the EJB 2 requirement to 'store before find', but I consider it 'Janus' headed: one side parfumed like a feature, the other one stinking like a workaround. Back to my past suggestion of respecting the ORDER of OO calls: A simple, but imperformant, solution would be to execute storeEntity() after each business method and in create/remove. I believe now, that the real flaw is caused by the fact, that the EJB specs consider every field/attribute of a bean to be equal in semantics to each other, with the exception of the Primary Key field(s). But they didn't learn their lession really from the relational poor mens! They COMPLETELY ignore the very different semantics of FOREIGN KEYS (place holders for Associations of all sorts). This discussion threads problem never comes up, when changing simple attributes/fiels, that ain't related to anything, but the primary key of the bean instance (1:1, normally). But it shows up, when attributes, that represent associations, are modified. JAWS/JBoss needs to know about the SEMANTICS of fields/columns and then can come up with performant/'intelligent' handling: If deferral to commit time is suggested, then QUEUING up all store requests related to one TX (including create(), remove() and store() and possibly find() for DIFFERENT instances/beans) will help: if ANY store request affects data with FOREIGN KEY / Association semantics, the queue must be processed physically to the underlying store, until empty, before executing the call with association semantics (only as a first attempt, we will be better in a few days!). Thus several changes to simple attributes of the same bean instance intermixed with creation/removal of other bean instances would nicely be accumulated to only one store() operation (and several unrelated create/delete_stores). But a change of a FOREIGN KEY / Association field would trigger the queue processing before doing the change to the assoc field, resolving this threads sort of problem. Further requests to simple attributes then again accumulate to the queue. Makes sense, doesn't it? Georg ___ ___ | + | |__ Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
