hi all,
i would vote (is there a poll?) for the strategy ole mentioned.
1. you will have to deal in the future with already existing database schema
2. a version number is meaningless in this matter, because you will not know
what version this record has - you will know if it is changed
3. the dirty flag is not sufficient
what is about the approach done in the container:
- create entity (WorkBuffer), clone it (SaveBuffer)
- on write create entity2(DBaseBuffer)
- check if WorkBuffer.attributes==DBaseBuffer.attribute -> nothing changed
- check if SaveBuffer.attributes<>DBaseBuffer.attributes -> database has
being changed
- look for unresolvable attribute conflicts -> exception
- check if WorkBuffer.attributes==SaveBuffer.attributes -> user has changed
attr
- update changed attributes
i am thinking of this, because reading/writing a int is more expensible for
the db roundtrip then two read tx.
2ct
bax
> -----Urspr�ngliche Nachricht-----
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]Im Auftrag von Ole Husgaard
> Gesendet: Samstag, 28. Oktober 2000 16:07
> An: jBoss
> Betreff: Re: [jBoss-User] Long-running pseudo transactions HOWTO
>
>
> Hi,
>
> Rickard �berg wrote:
> > marc fleury wrote:
> > > It doesn't address the client holding of the version he is
> looking at (the
> > > client gets a "copy" of the values and when he comes back he
> needs a version
> > > number)
> >
> > The client gets a snapshot of the data, INCLUDING a version number.
> > Client then edits that data. The the client sends back the data. If the
> > version on the server is the same as in the snapshot the client is
> > sending back, then all is well. If there is a mismatch then some other
> > client made an update, and the client gets an exception.
>
> I believe this pattern to be widely used. For example Nordija has
> a publicly available web interface (at www.nordija.com or
> www.nordija.dk, I don't remember) to some bean generator that
> generates beans that do this.
>
> Personally I don't like it as it adds extra state (version number)
> that the client needs to have.
>
> Another pattern that does not add extra state, but creates a little
> more traffic on updates can be exemplified by:
> We have a Person entity bean and an Address value object. The
> Person bean has normal bean pattern for accessing and modifying
> the address property:
> Address getAddress();
> void setAddress(Address adr);
>
> The problem is the same as above: If we want a user to edit the
> address and update it in the bean we risk that another user
> updates it too while the user is editing. The simple fix is to
> have a single ACID transaction spanning the whole get-edit-update
> process, but that is undesirable as nobody knows how long it may
> take the user to edit (ie. lunch break during editing). To get
> around this a logical business transaction is done so that get
> and update are ACID transactions that are part of the business
> transaction, but the edit step is outside any ACID transactions
> but inside the business transaction. Problem with this is that
> another user can update the address during the first user's
> editing.
>
> This could be fixed by adding a data version number as proposed,
> but there is another way:
> Instead a new method
> void setNewAddress(Address oldAdr, Address newAdr)
> throws ConcurrentUpdateException;
> is added and used for the update step of the business transaction.
> The oldAdr argument is the address that the user read on start of
> the business transaction, and newAdr the the result of user
> editing. If the current contents of address in the Person bean
> is not equal to oldAdr or newAdr, an exception is thrown.
> Besides the fact that no extra state is needed with this approach,
> this has the added advantage that concurrent edits do not cause
> an exception if:
> a) Another field is changed.
> b) The same field is changed, and then changed back to the old
> value before the original business transaction does the
> update.
> c) If the same field was changed to the new value. In this case
> the update is just a no-op.
>
> In any case, I do not think that support for business
> transaction should belong to the EJB container or server.
> IMHO this is better done by bean programmers and generators.
>
> Why? Business transaction may be _very_ complex. The "user
> edits some data" business transaction is just a very simple
> example.
> A more complex example could be found in an order entry system,
> where "create a new order" is a business transaction with
> the following requirements:
> - Other users should not see the new order until the business
> transaction is committed.
> - Stock inventory should be pre-allocated as the user enters
> each new order line, so that the business transaction commit
> will not fail with an out-of-stock exception.
> Even Peter Herzum (who advocates the notion of business
> transactions) acknowledges that even with extensive framework
> support for business transactions, only about 80% of all
> business transactions can be done within the framework.
>
>
> Best Regards,
>
> Ole Husgaard.
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
