On Wed, 5 Jan 2000, Kucera, Rich wrote:
> Where's the beef in EJB anyway? I thought we had a transactional layer in
> middleware with ejb...
> datasources wouldn't necessarily need to be transactional themselves (they
> wouldn't need to be
> full-blown databases).
You can't do it. In the end there has to be some kind of atomic
transactions in the database otherwise you might get inconsistent data if
the container crashes.
This is a very important point. I noticed that the mysql site now lists
transactions as the number one feature to implement. However, they still
mentions "transactions will rollback" in the section "things we don't have
any plans of implementing". Watch out for that. Their "transactions" will
most certainly just be a wrapper around the lock/unlock tables mechanism.
This will just provide protection from race condifitions when several
connections access the database as the same time, it does not guarantee
data integrity if a client crashes. Or the server crashes, for that
matter.
So if you want to guarantee transaction integrity using mysql you have to
reload the backups every time a client or the server has crashed. This
means that you will lose data because there is no transaction log to
rollback efter the backup has been reloaded. In my opinion, doing this is
much more expensive than getting a real database.
/E.
