Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user-java@ibatis.apache.org
Received-SPF: pass (nike.apache.org: domain of alistair.young@logica.com
 designates 216.32.181.16 as permitted sender)
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: iBATIS caching / transaction isolation question
Date: Mon, 19 Jan 2009 09:22:51 +0000
Message-ID: <A07ECA086F63AC488A70CCC5DB1CEF780CF2515B@uk-ex007.groupinfra.com>
Thread-Topic: iBATIS caching / transaction isolation question
thread-index: Acl0ycHn0Shy7tiJQzaOKP1NKR38OgAB2ZIwAIqnvbAAxsF+IA==
References: <A07ECA086F63AC488A70CCC5DB1CEF780CDDA9AE@uk-ex007.groupinfra.com>
 <16178eb10901120723xa991fc6mebcd95404de6326d@mail.gmail.com>
 <A07ECA086F63AC488A70CCC5DB1CEF780CDDAF1A@uk-ex007.groupinfra.com> 
From: "Young, Alistair" <alistair.young@logica.com>
To: <user-java@ibatis.apache.org>

Me again... :)

I was having a think about this over the weekend and realized that the beha=
viour I'm after would be very difficult to implement (and possibly very ine=
fficient), so perhaps iBATIS does NOT behave in this way.

It struck me that, if iBATIS were maintaining multiple caches AND paying at=
tention to transaction boundaries the cache flushing logic would become ver=
y complex.  For example, if thread A executed an 'update', iBATIS would hav=
e to flush the corresponding cache for that thread only.  If the transactio=
n were later rolled back, iBATIS would have to flush that cache again.  How=
ever, if the transaction were committed, it would have to flush all OTHER c=
aches...

So, I've come to the conclusion that the only way to use caching safely is =
to ensure that no cached SELECT statements are executed within transactions=
 that may ultimately be rolled back.

I'd appreciate some input from anybody making use of iBATIS caching - is th=
is a rule you've had to adhere to?

Cheers,


Alistair.

-----Original Message-----
From: Young, Alistair =

Sent: 15 January 2009 10:31
To: 'user-java@ibatis.apache.org'
Subject: RE: iBATIS caching / transaction isolation question

Sorry to rake this up again...  I hope you don't mind if I ask a couple of =
questions about the expected behaviour of iBATIS in this area.

1. Should different threads, sharing an SqlMapClient object, be seeing the =
SAME cache or DIFFERENT caches?  I would expect the latter (though the beha=
viour I'm seeing suggests the former).

2. If a transaction is rolled back, should the cache be flushed?  I would e=
xpect yes but, again, my tests suggest no.

Fundamentally, I'd just like to know whether I'm mis-using iBATIS, or wheth=
er I'm going to need to manage the caching myself (custom CacheController?)=
 if I want things to behave as above.

Cheers,


Alistair.

-----Original Message-----
From: Young, Alistair [mailto:alistair.young@logica.com]
Sent: 12 January 2009 16:36
To: user-java@ibatis.apache.org
Subject: RE: iBATIS caching / transaction isolation question

Many thanks for the reply, Clinton - but sadly this doesn't seem to fix the=
 problem.  My understanding was that readonly need only be set to "false" i=
f a thread is likely to change the contents of the returned object - this i=
s not the case in my example application (indeed, the returned object is a =
String).

I've appended my code and iBATIS configuration files below - I'd appreciate=
 it if you could tell me if I'm doing anything obviously wrong.  My underst=
anding was that a SqlMapClient object could safely be used from multiple th=
reads (and that it would handle the caching appropriately).

Thanks,


Alistair.

IBatisTest.java:
------------------------------------------------------------
package test;

public class IBatisTest implements Runnable {

    private SqlMapClient sql;
    =

    public IBatisTest() throws Exception {
        // create the SQL map
        Reader reader =3D Resources.getResourceAsReader("SqlMapConfig.xml")=
;
        this.sql =3D SqlMapClientBuilder.buildSqlMapClient(reader);
    }
    =

    public void runTest() throws Exception {
        =

        this.sql.startTransaction();

        String value =3D (String)this.sql.queryForObject("db.getValue");
        System.out.println("Value is " + value); // "1"
        =

        this.sql.update("db.updateValue", "2");

        value =3D (String)this.sql.queryForObject("db.getValue");
        System.out.println("Value is " + value);  // "2"
        =

        // start the other thread
        new Thread(this).start();
        =

        // wait for a bit
        Thread.sleep(2000);

        // roll back the transaction        =

        this.sql.endTransaction();
        =

        value =3D (String)this.sql.queryForObject("db.getValue");
        System.out.println("Value is " + value); // "2" (expecting "1")
    }
    =

    // second thread
    public void run() {
        try {
            String value =3D (String)this.sql.queryForObject("db.getValue")=
;
            System.out.println("    Value is " + value); // "2" (expecting =
"1")
        } catch (Exception x) {
            throw new RuntimeException(x);
        }
    }

    public static void main(String[] args) throws Exception {
        new IBatisTest().runTest();
    }

}
------------------------------------------------------------

SqlMapConfig.xml:
------------------------------------------------------------
<?xml version=3D"1.0" encoding=3D"windows-1252" ?>

<!DOCTYPE sqlMapConfig
    PUBLIC "-//ibatis.apache.org//DTD SQL Map Config 2.0//EN"
    "sql-map-config-2.dtd">
    =

<sqlMapConfig>

    <settings
        useStatementNamespaces=3D"true"
        lazyLoadingEnabled=3D"true"
        enhancementEnabled=3D"true"
        statementCachingEnabled=3D"false" />

    <transactionManager type=3D"JDBC">
    =

        <dataSource type=3D"SIMPLE">
            <property name=3D"JDBC.Driver" value=3D"oracle.jdbc.OracleDrive=
r"/>
            <property name=3D"JDBC.ConnectionURL" value=3D"..."/>
            <property name=3D"JDBC.Username" value=3D"..."/>
            <property name=3D"JDBC.Password" value=3D"..."/>
        </dataSource>
        =

    </transactionManager>
    =

    <!-- at least one SQL Map is required for this to be a
         valid configuration file -->
    <sqlMap resource=3D"SqlMap.xml"/>
    =

</sqlMapConfig>
------------------------------------------------------------
 =

and SqlMap.xml:
------------------------------------------------------------
<?xml version=3D"1.0" encoding=3D"windows-1252" ?>

<!DOCTYPE sqlMap
    PUBLIC "-//ibatis.apache.org//DTD SQL Map 2.0//EN"
    "sql-map-2.dtd">
    =

<sqlMap namespace=3D"db">

    <cacheModel id=3D"cache" type=3D"FIFO" readOnly=3D"false" serialize=3D"=
true">
        <flushOnExecute statement=3D"db.updateValue"/>
        <property name=3D"size" value=3D"10"/>
    </cacheModel>

    <insert id=3D"updateValue" parameterClass=3D"String">
        update VALUES set VALUE=3D#value# where ID=3D1
    </insert>
    =

    <select id=3D"getValue" resultClass=3D"String" cacheModel=3D"cache">
        select VALUE from VALUES where ID=3D1
    </select>
        =

</sqlMap>
------------------------------------------------------------

-----Original Message-----
From: Clinton Begin [mailto:clinton.begin@gmail.com]
Sent: 12 January 2009 15:23
To: user-java@ibatis.apache.org
Subject: Re: iBATIS caching / transaction isolation question

The uncommitted data would be seen by thread B as you expect, *if* the cach=
e 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.young@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 =E0 pr=E9server l'environnement en =E9vitan=
t =

> 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=E3o imprimindo este correio electr=F3ni=
co.
>
>
>
> 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


Please help Logica to respect the environment by not printing this email  /=
  Merci d'aider Logica =E0 pr=E9server l'environnement en =E9vitant d'impri=
mer ce mail /  Bitte drucken Sie diese Nachricht nicht aus und helfen Sie s=
o Logica dabei die Umwelt zu schuetzen  /  Por favor ajude a Logica a respe=
itar o ambiente n=E3o imprimindo este correio electr=F3nico.


This e-mail and any attachment is for authorised use by the intended recipi=
ent(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 recipien=
t then please promptly delete this e-mail and any attachment and all copies=
 and inform the sender. Thank you.


Please help Logica to respect the environment by not printing this email  /=
  Merci d'aider Logica =E0 pr=E9server l'environnement en =E9vitant d'impri=
mer ce mail /  Bitte drucken Sie diese Nachricht nicht aus und helfen Sie s=
o Logica dabei die Umwelt zu schuetzen  /  Por favor ajude a Logica a respe=
itar o ambiente n=E3o imprimindo este correio electr=F3nico.


This e-mail and any attachment is for authorised use by the intended recipi=
ent(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 recipien=
t then please promptly delete this e-mail and any attachment and all copies=
 and inform the sender. Thank you.