Hi,
A couple of comments
1. I think the worst problems can be eliminated by simply extending Bill's
"store before load" to include "store before remove" and possibly "store
before create" although I don't have an example of why the last one would
help.
2. There are probably some examples of how to get into trouble by executing
updates in a different order than the ejb methods were called, however this
is apt to lead to 1 db access / entity ejb method call, so you might as
well do every db synchronization immediately. I'm not sure this is
desirable. Often these tricky sequential access problems can be solved by
writing a stored procedure, so perhaps a more widely useful goal would be
to make it possible to specifiy for JAWS to use stored procedures for
insert, update, and delete operations.
3. The effects of triggers are different from another app modifying the
data, at least with real acid transactions. Remember, read committed is
not ACID (incomplete I). I think most people use them because most
databases don't support better isolation at a reasonable speed. I don't
think starting a transaction, loading a bean, waiting a while for changes
to get committed in another transaction, then reloading the same row is a
common or good strategy. I think loading the bean at some point in your
transaction and assuming noone else is changing it before you commit is
what most people do. So the commit options are to control whether to
reload at the beginning of a new transaction or to assume that the last
cached values are still accurate. However, note that with Bill's fix you
can always refind all your affected beans after you do an operation firing
a trigger. The new finds will force all updates to the db, firing the
triggers, so you will read the new data.
david jencks
On 2001.06.16 00:44:45 -0400 Georg Rehfeld wrote:
> Hi all,
>
> trying to sort that out.
>
> David Esposito showed us a perfectly OK sequence of modifications
> to some Entity beans within one TX. He reported problems with JBoss
> accessing the DB while persisting, because of changed order of
> modifications, creates/deletes seem to be done before updates,
> regardless of the OO sequence of calls.
>
> This comes surprising to me, anybody around to tell, if and why
> this is the case? Is it only with CMP somehow, I can't see this
> with BMP?
>
> Everything would be OK, if JBoss did sync in the very same order
> to the DB as the OO code requested it. Regardless of doing the
> ejbStore() at the end of TX or after calling a business method:
> just do it in the same order. Even intermixed stores would be
> no problem, when done IN THE SAME ORDER (this respecting the
> recent change to finders doing a store before finding, as requested
> by EJB spec 2.0).
>
> Please remember: a TX on a DB actually SEES the changes it has
> done in it, although no other TX can see that until commit.
>
> Now to the RI (referential integrity) thing:
>
> A DB RI setting of ON DELETE CASCADE must be considered as beeing
> another application modifying the DB concurrently to JBoss, so
> the commit option HAS to be set to at least B, and the code in
> the beans then MUST be prepared to accept concurrent changes
> by some app outside JBoss and handle that gracefully. I.e. in
> Davids case he must be prepared to expect cc.setRecord() to fail
> IF HE HAD called mca.remove() HIMSELF BEFORE or IF HE HADN'T
> FETCHED mca BEFORE modification to cc ... but his code still is OK.
>
> A DB RI setting of checking validity of Foreign Keys should not
> be problematic even with commit option A (note off topic: depending
> on your mapping of inheritance to your DB this COULD be a problem).
>
> Besides, not changing the order of access to the DB leaves control
> of LOCKING to the bean implementor, thus DEADLOCK avoidance is to
> him ... but he hasn't the same possibilities, as the typical
> relational DB developer has: the RDB developer always can ROLLBACK
> when he discovers, that some required lock can't be aquired (SELECT
> ... FOR UPDATE NOWAIT for Oracle, similar for other RDMS's).
>
> The EJB developer is lost here, the spec simply drops him
> 'serialized' possibly waiting for a bean held by his competitor
> which itself is blocked cyclic. The only way to handle deadlock
> is 'ordered access', which in practice seems to be impossible,
> especially respecting the above requested access to the DB in
> the same order, as the OO code needs/expects it.
>
> There is a hint in the EJB specs 1.1, that the container might
> reorder access to the DB to actually try ORDERED access to the
> DB (i.e. in increasing PK order) to avoid deadlock. But I just
> now can't come up with a pattern, that is safe and avoids deadlock,
> any taker?
>
> Conclusion: today let JBoss respect the OO order of access to
> beans and do it the same way to the DB.
>
> regards
> 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
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
