answering my own question I think, but from doing some test cases, it appears I
still need the SERIALIZABLE isolation level in the above example using a
CacheLoader, as 2 threads trying to read the same (empty/null) value will both
go "hunting" in the db and clobber the first ones value.
Test
This relates to my other post "SERIALIZABLE Bug? Read of null, put, another
thread reading", and I just wish to clarify something.
Assuming a rather simplistic TreeCache usage, where all Fqn would be of the
form "/23" where the number is really the ID of the object row in the DB.
If I implement
I had a look at CacheLoader's over the weekend, but not quite sure what I would
actually need to implement.
To 'build' the object that needs to be cached requires invoking a custom object
which handles all the Data retrieval and building, and because of legacy code,
there is _no_ concept of tr
Thanks. I can imagine changing the behaviour now would hurt many people. I
wonder if it's a optional setting that could be implemented?
Anyway, I am thinking of placing a traditional synchronized(...) block
initially so that no thread could ever read null.
View the original post :
http://w
http://www.mssqlcity.com/Articles/General/TIL.htm defines (from SQL Server
reference) that SERIALIBLE is as follows:
anonymous wrote :
| Phantom behavior occurs when a transaction attempts to select a row that
| does not exist and a second transaction inserts the row before the first
| t
Sure, I can understand why it's doing it, but I was under an impression that
it's a violation of the contract for SERIALIZABLE. Am I wrong? (statistics
show that I am.. :D)
If we pretent do be a DB for just a moment, doesn't SERIALIZABLE dictate that
no other connection can create a new row in
Thanks to Norbert and Bela for the reply.
I tested Norberts theory on Thread start position, and it didn't seem to make
any difference.
I took Bela's test case, and this test does work, BUT WITH ONE subtle
difference.
In Bela's test case, he places a value in the cache before starting things.
I'm not sure if this is a bug, or a feature I can't have! :)
Lets assume a local TreeCache with isolation Level set to Serializable.
Initiall when the cache is empty, the initial read will of course return null.
Lets assume within this same transaction for this first thread that this thread
t
