Let's say you write an order to an order table, and three line
items to a child line item table. Then you have some sort of problem
which causes a rollback (a line item has an order quantity of -1, refers
to a non-existant catalog number, etc.). Now, if you have no
transactions, you have a partial order in your database - an order record,
and some but not all line item records. Worse yet, you may have enabled
transactions in MySQL for one table but not the other. Now you have an
order with no line items, or even worse, some line items with no order.
And if you're generating sequential IDs for orders and the order ID wasn't
written, you may reuse the ID later, which would either result in extra
line items on someone else's order or a PK violation when you go to write
line item #1 on the subsequent order.
Now, I've outlined a variety of potential problems, and you could
probably work around those specific problems, but all of these represent
"data corruption", and one of the reasons people use J2EE is so they don't
have to try to manually deal with crap like that.
Aaron
On Thu, 9 Nov 2000, Tobias Frech wrote:
> Thanks Aaron for pointing this out.
> I still do nut fully understand the implications of not having any
> transactions on the database level. As long as just one application
> server uses the database I can't see how data could get corrupted. I
> thought the application server guarantees to have synchonized business
> method calls. And after each call the data is stored back into the
> database. Where does the corruption come in ?
>
> Will transactions allow me to run two or more application servers with
> just one _shared_ database ?
>
> BTW: For such useful information I suggest to include a <comment /> tag
> into jaws.xml. Can I just include it or does the DTD have to altered ?
>
> Thanks,
> Tobias
>
>
> Aaron Mulder wrote:
> >
> > Please note that you must use extreme caution with mySQL: it did
> > not support transactions until very recently (v 3.23.6?), and even now you
> > must install an add-on product and specifically indicate that *each table*
> > should be transaction-safe when you create it. Since the default table
> > type is not transaction-safe, *you cannot allow JAWS to create tables for
> > you*, and that means this mapping is not very useful.
> > Because nearly all MySQL installations are not set up for
> > transactions, and J2EE depends on databases supporting transactions, we
> > strongly recommend that you consider another product (such as
> > PostgreSQL). If you are absolutely sure that everything is set up
> > correctly for transactions, and you manually create all tables that your
> > EJBs will use, then it should work, but again I would recommend mySQL only
> > as a last resort - if you make any mistakes in the configuration, you are
> > setting yourself up for data corruption.
> >
> > Aaron
> >
> > On Wed, 8 Nov 2000, Tobias Frech wrote:
> > > Hi mySQL users!
> > > As my new and tested mySQL type-mapping didn't make it into the new beta
> > > (Sebastien, how are you?) I'd like to post it here to make the live
> > > easier for all you guys who want to use mySQL. Tested with
> > > dbtest/AllTypes package.
> > >
> > > for [standard]jaws.xml:
> <mapping deleted. look in older mails>
> > > You'll find additional docu under bug #219 and #220
> > > (http://www.telkel.com/bugzilla/).
> > >
> > > Have phun.
> > >
> > > Tobias
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
