ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Zeigermann <oliver.zeigerm...@gmail.com>
Subject Fwd: A few dumb questions
Date Mon, 29 Nov 2004 22:37:52 GMT
My bad gmail acoount... This should have gone to the list, I guess...

Oliver


---------- Forwarded message ----------
From: Brandon Goodin <brandon.goodin@plumcreek.com>
Date: Mon, 29 Nov 2004 15:33:08 -0700
Subject: Re: A few dumb questions
To: ozeigermann@apache.org


 
>Having read a number of answers I now think I understand. I write the
>SQL, so I am responsible for the dialect and thus ibatis works for all
>dbs, right? 
  
correct

>If so is there any support for me supporting a number of databases? I
>nice way to handle different dialects? 
  
I would say that 95% of the dialect you use will be cross-database.
and most of the other 5% will be in stored procedures.
  
It is up to you to setup your config files in such a way that you can
keep the small percentage that needs to be rewritten in separate
config files for organizational purposes.

> I see. How does it relate to 
> http://jakarta.apache.org/commons/dbutils/
 
I'm not familiar with dbutils. It looks a bit more low-level. Feel
free to provide a side by side comparison. It'd be great to learn it's
benefits and whether it has any features we can adopt.

> I understand this is true for caching. I thought dirty checking
> usually is done inside a transaction where I can be pretty sure the
> data I have just read has not been changed in the meantime. Am I
> wrong? 
  
Hopefully other committers and experts will chime in on this one. But,
here goes my opinion.
  
Taking a moment to think about dirty checking.... 
  
You have to store every object you desire to manage in a location
along with every object nested within that object identified by a key.
So, you have to configure ahead of time what the key will be. For each
record in your resultset you would need to see whether it already
exists in your object layer by the key and update it accordingly.
Also, within your transaction you get a version of that object to use
within your thread's execution. If you make a change to that object
you have to be aware that each change to that object may result in an
update to the global object and to the database in order to keep all
the other objects in sync with it. An update to an object while
another object is checked out will result in a stale data error of
some sort (assuming you are maintaining version checking). I may be
incorrect about each thread having it's own copy of an object. But,
regardless, the need to constantly "check" and update the object to
keep items in the same application in sync shows that there is still
potential for application collisions. If your database is the common
share point of an enterprise system I think it is the best dirty
checker to date. It gives you what you want from the source.
  
That being said, I don't have a closed book on dirty checking. It is
something that I am certainly willing to talk more about. I may have
some misconceptions floating around in my head. But, as far as I can
tell...it's accurate.
  
My philosophy is to use the database. The database is my friend. 
  
Brandon

Mime
View raw message