Hi Bruno,
1) By container-managed I mean the container (such as JBoss) is doing
transaction management instead of Cayenne. This typically is not the
case (I've never used container-managed). There is a checkbox in
Cayenne Modeler (on the DataDomain editor) to control this.
Regardless of that checkbox, though, the database is ultimately
managing the transaction. This is pretty standard and what you want.
2) Optimistic locking is implemented by Cayenne, not the database. It
is a strategy to protect data without actually locking rows/pages in
the database (if the database even supports locking). It is
database-agnostic and very reliable. Much more reliable than a
version number (which I believe is the default behavior for
Hibernate).
3) I still wouldn't use MySQL for finances. :-)
mrg
On Thu, Oct 28, 2010 at 10:53 AM, Bruno René Santos <brunoren..olos.pt> wrote:
> Hi Michael,
>
> Thanx for the answers. About point 1, when you talk about the 'container', what
> do you mean? So you're telling me the default transaction engine Cayenne uses is
> from the DB, not managed by cayenne programmatically (cayenne calls BEGIN
> TRANSACTION and COMMIT from the DB)?
>
> About point 2, I was asking your opinion about the degree of reliability on
> comparing cayenne's optimistic locking with lockings from the DB. Or do you mean
> cayenne uses this mechanism straight from the DB? I was always a little confused
> about if cayenne implemented these two mechanisms (transactions and locking) or
> just called the proper methods from the DB.
>
> Thanx a lot
>
> Bruno
>
> -----Mensagem original-----
> De: Michael Gentry [mailto:mgentr..asslight.net]
> Enviada: quinta-feira, 28 de Outubro de 2010 15:16
> Para: use..ayenne.apache.org
> Assunto: Re: Cayenne Transactions vs MySQL Transactions
>
> 1) Cayenne does a begin transaction and end transaction when it
> commits (assuming you aren't using container-managed transactions, in
> which Cayenne is deferring that operation to the container). Are you
> at least using InnoDB with MySQL? MySQL hasn't had the best track
> record for handling transactions/rollbacks.
>
> 2) I'd say optimistic locking is critical especially in a financial
> application. Maybe you wouldn't need/want it for a Facebook, but you
> certainly want it when integrity of the data is important. Cayenne's
> optimistic locking is more reliable than using a version number or
> time stamp column.
>
> 3) Are you really using MySQL for a financial application? MySQL
> likes to silently (without error) change data on you. This can lead
> to data loss without you ever knowing about it.
>
> mrg
>
>
> On Thu, Oct 28, 2010 at 9:54 AM, Bruno René Santos <brunoren..olos.pt> wrote:
>> Hello all,
>>
>>
>>
>> First, sorry about so many doubts in so little time, but I’m trying to decide
>> how to do some things on my application concerning cayenne. So adding to my
>> previous doubts, here goes some more doubts:
>>
>>
>>
>> 1. Do cayenne transactions guarantee consistency as MySQL transactions
>> guarantee?
>>
>> 2. Do you think cayenne’s optimistic locking is reliable enough to use
> on
>> a financial web application with money movements between accounts, where you
>> could have lots of people messing with the same accounts? If not, how can use
> a
>> regular lock from the MySQL DB? With a performNonSelectingQuery?
>>
>>
>>
>> Thank you so much
>>
>> Bruno Santos
>>
>> --
>>
>>
>>
>> Bruno René Santos | Gestor de Projectos - Project Manager |
>> <mailto:brunoren..olos.pt> brunorene@holos.pt | <http://www.holos.pt>
>> http://www.holos.pt
>>
>>
>>
>> Holos - Soluções Avançadas em Tecnologias de Informação S.A.
>>
>> Parque de Ciência e Tecnologia de Almada/Setúbal . Edifício Madan Parque
>>
>> Rua dos Inventores . Quinta da Torre . 2825 - 182 Caparica
>>
>> Phone: +351 210 438 686 . Fax: +351 210 438 687
>>
>>
>>
>> This email and any files transmitted with it are confidential and intended
>> solely for the use of the individual or entity to whom they are addressed. If
>> you are not the intended recipient or the person responsible for delivering
> the
>> email to the intended recipient, be advised that you have received this email
> in
>> error and that any use, dissemination, forwarding, printing, or copying of
> this
>> email is strictly prohibited. If you have received this email in error please
>> notify Bruno René Santos by telephone on +351 210 438 686
>>
>>
>>
>>
>
>
This archive was generated by hypermail 2.0.0 : Thu Oct 28 2010 - 15:25:06 UTC