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 Re: A few dumb questions
Date Tue, 30 Nov 2004 16:51:45 GMT
On Mon, 29 Nov 2004 17:02:26 -0700, Brandon Goodin
<brandon.goodin@plumcreek.com> wrote:
>  
> I guess I don't see how what you are saying solves the problem I am stating.
>   
> 1) I send a sql statement to the database it returns a resultset 
> 2) The resultset is iterated and keys are examined to see if the objects
> exist in the application object layer already. 
> 3) If the object does not exists it is created and added to the object
> layer. If the object does exist it is not created and the object in the
> object layer is left alone 
> 4) I get a copy of the object from the object layer 
> 5) I make changes to my copy of the object 
> 6) My persistence solution examines my object against the object in object
> layer and updates the database with a crafted update statement. 
> 7) database and object are in sync 
>   
> Question: 
>   
> So, looking at step 3 how does the persistence solution know that the record
> in the database is the same when the object in the object layer has been
> retrieved already and another completely different application altered its
> related record in the database? 

I think I understand what you mean. The simple solution is to allow
dirty checking inside of transactions only. I.e. as soon as you commit
or rollback the dirty copies will be invalidated. Inside of a
transaction reads should be repeatable, so the data can not be changed
by other applications. Using this outside of transactions would be
what I called caching which indeed will be affected by what you
describe. As said before invalidation timeouts or even notifications
could soothe, but no heal the problem.

Maybe I am off track here?!

Oliver

Mime
View raw message