The uncommitted data would be seen by thread B as you expect, *if* the
cache is configured as read-only.
To stop this problem, set the cache to read/write and serializable.
Sorry for the confusing configuration here.
Clinton
On 1/12/09, Young, Alistair <alistair.yo...@logica.com> wrote:
> Apologies for following up my own post...
>
> I carried out a simple test and found that transaction isolation is not
> maintained. Also, the cache is not flushed in the event of a
> transaction being rolled back.
>
> The sequence of events was:
>
> Thread A: start transaction
> Thread A: select value ("1" is returned)
> Thread A: update value to "2"
> Thread A: select value ("2" is returned)
>
> Thread B: select value ("2" is returned - not "1")
>
> Thread A: rollback transaction
> Thread A: select value ("2" is returned - not "1")
>
> Is this the expected behaviour?
>
> If not, what might I be doing wrong? If so, how do people deal with
> this behaviour?
>
> Thanks for any advice,
>
>
> Alistair.
>
> ________________________________
>
> From: Young, Alistair
> Sent: 12 January 2009 10:54
> To: user-java@ibatis.apache.org
> Subject: iBATIS caching / transaction isolation question
>
>
> Hello all,
>
> I wonder if somebody could clarify for me how iBATIS caching works with
> regards to transaction isolation.
>
> Suppose I have a cache set up with is used when a "selectAllItems"
> statement is invoked, and flushed when an "updateItem" statement is
> invoked.
>
> Suppose then that thread A starts a transaction, invokes updateItem and
> then selectAllItems. Then, before thread A completes the transaction,
> thread B invokes selectAllItems.
>
> Is transaction isolation maintained, or does thread B end up seeing the
> (uncommitted) data that thread A has updated?
>
> I should add that I haven't actually tried this yet - but I'd like to
> know what the expected behaviour is before getting stuck in.
>
> In our particular use case, we're making use of a custom
> TransactionConfig (which is essentially the same as "EXTERNAL" but
> handles connection creation slightly differently). And we're not making
> any explicit calls to the iBATIS transaction methods.
>
> Many thanks!
>
>
> Alistair.
>
>
>
>
> Please help Logica to respect the environment by not printing this email /
> Merci d'aider Logica à préserver l'environnement en évitant d'imprimer ce
> mail / Bitte drucken Sie diese Nachricht nicht aus und helfen Sie so Logica
> dabei die Umwelt zu schuetzen / Por favor ajude a Logica a respeitar o
> ambiente não imprimindo este correio electrónico.
>
>
>
> This e-mail and any attachment is for authorised use by the intended
> recipient(s) only. It may contain proprietary material, confidential
> information and/or be subject to legal privilege. It should not be copied,
> disclosed to, retained or used by, any other party. If you are not an
> intended recipient then please promptly delete this e-mail and any
> attachment and all copies and inform the sender. Thank you.
>
>
--
Sent from my mobile device
