Hey
Good questions!
Yasuaki Sugino wrote:
> -- Deadlocks are possible when trying to serialize calls that generate nested
> calls to another E-Bean method.
Which is why the tx timeout is very important to solve such deadlocks
(besides getting rid of them by design). Transactions which are deadlock
prone should be put into while-blocks to ensure that they got done in
the event of a deadlock:
while(true)
{
try {
tx.begin();
a.dostuff();
b.dostuff();
c.dostuff();
break;
} catch (Exception e)
{
// Retry in case of deadlock or other tx-failure (exception handling
should also be more detailed)
}
}
(or similar)
> -- Long transactions are blocking other accesses; in particular "read"
> accesses, with no reason. We do not want to block an E-Beans for read when
> another client writes it and has not committed yet. (non-blocking writes
> are typically provided by database vendors like Oracle).
Just a hunch: would it be possible to mark the bean as "TX_REQUIRES" but
mark those methods not needing tx:s ("read":s) as "TX_NOT_SUPPORTED"?
Would that yield a "non-blocking read"-effect?
> 3. Cache management
> Some caching Options (9.11.4) are suggested, but only in the context of
> transactions. They need to be extended to support concurrency as well as
> recovery.
Cache management when not in a transaction (i.e. TX_NOT_SUPPORTED is
used) is interesting. When should ejbLoad/ejbStore be called? Whenever?
After each call ("just in case")?
/Rickard
--
Rickard �berg
Computer Science student@LiTH
@home: +46 13 177937
Email: [EMAIL PROTECTED]
Homepage: http://www-und.ida.liu.se/~ricob684
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
