A little problem with transaction and persistent objects like entities: Picture this: An application is accessed by some means of asynchronous device such as a web-browser (suprise!). Therefor one does not want to start a "physical" transaction for each "gui" transaction. Where "gui" transaction is a user-experienced transaction, like for example a dialog box with "OK" and "Cancel" buttons. The reason for this is that "physical" transactions takes up too much resources and probably will have timeout a couple of zeros away from what a user experiences as a good timeout. Ok, this is no surprise. I bet we're all working this way under these conditions. The solution is an application of the probably most famous design patterns of EJB so far. The "Session as a facade to Entity"-pattern. We cache the state of the "gui" transaction in a SessionBean (could also be the some objects associated with http-session). When the user presses "OK" the "physical" transaction is started and the data is flushed into the entities. Or something like this, there are probably as many variants of as there are ejb-architects. Ok, here comes the problem. What if the user was editing some kind of complex entity consisting of various values and options with relations and constraints binding them all together. When the user edits the entity he would like to interactively see the result of editing the values. If he feels satisfied with the editing he "commits" the "gui" transaction, if he's not he "rolls it back". If the calculations are complex they would want to be implemented using the oo-niceties of the EntityBeans but there is a problem. Since the entity-beans are by definition transactional and persistent if the session-bean facade edited the fields and read back the result (ie. performed a "simulation" hence the subject) a transaction would be started and the "simulation" would be commited, which was not at all what the user wanted. The way to get around this is to put the "business-logic" in the session-bean and perform the calculations on the "cached" data instead. But suppose the calculations is some kind of invariant, entity-specific calculations and not (as we say it) process-specific (ie. related to the session-bean facade), then the calculations has to be put on both places, or in a place where both could access it. In the last case it (and this is where it gets really creepy) has to be put in some sort of "library", ie. using functional decomposition (the oh-so infamous anti-pattern). The other way is to simply use bean-demarcated transactions, start a transaction, set it to rollback only, perform the simulation and roll it back. But this also gives me a strange gut-feeling. (Although I've used this strategy before when working directly to database.) Ok, bean providers, how do you solve this, and, container providers, what solution do you recommend (let me see those <vendor>-tags :). Jon Tirs�n Chief Architect Itec Open Business Integrator AB PGP key lookup: http://certserver.pgp.com:11371/pks/lookup?op=get&search=0xE9032B9A
BEGIN:VCARD VERSION:2.1 N:Tirs�n;Jon;;; FN:Jon Tirs�n ORG:Itec; TITLE:Chief Architect TEL;WORK;VOICE:+46 (8) 343431 TEL;CELL;VOICE:+46 (709) 306109 TEL;WORK;FAX:+46 (8) 343438 ADR;WORK:;;Box 23049;Stockholm;;104 35;Sweden LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Box 23049=0D=0AStockholm 104 35=0D=0ASweden ADR;POSTAL:;;Ynglingagatan 17;Stockholm;;104 35;Sweden LABEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Ynglingagatan 17=0D=0AStockholm, 104 35=0D=0ASweden URL: URL:http://www.itec.se EMAIL;PREF;INTERNET:[EMAIL PROTECTED] EMAIL;INTERNET:[EMAIL PROTECTED] REV:19990417T134712Z END:VCARD
