Ivan Koblik

+ Follow
since Apr 22, 2008
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Ivan Koblik

I think it is presumed that classes within a package are usually written by the same developer and consequently it is safe to give her/him more access rights, like the default access to all the protected class members.
Other packages, on the contrary, may be written by some other developers, so here we see more constraints being imposed.
15 years ago
Hello Monu,

As I see it, your test proves only that daemon threads are killed when there is no more other threads alive.

Daemon thread, as any other kind, dies if it exits the run() method. So it is the developer's responsibility to keep it alive.

In the first test, program was running long enough to allow the daemon thread finish its execution.
[ December 03, 2008: Message edited by: Ivan Koblik ]
Mike thanks for the insight, I didn't see the potential issue. I have reread the article that I gave a link to in my first post: The Limits of Code Optimization: a new Singleton Pattern Implementation.
So you can either use volatile variable or some oracle function that always returns true but cannot be optimized by java (please see the article, it should also pretend to use the results of theMethod()). This way you can have a working DCL in Java 1.4
Mike, doesn't Java reconcile all the variables with the main memory when entering synchronized block? Please see: Use synchronized or volatile.
On the second point you're right, flag should be set to true only after completion of theMethod(). Sorry about that.
Hello Meir Yan, in your case the Double-Checked Locking (DCL) may be of help.
At this page you will find more then enough on DCL.
Basically you need to do the next

[ December 02, 2008: Message edited by: Ivan Koblik ]
I also did a test that proves that Oracle actually does provide serializable access to read-only transactions.
Create a table with one column named ID and with three records 1,2,3.
In debugger execute next code up to -->.

execute in another window

Then run the code that was frozen in the debugger. c is equal to 3, access was really serializable!
[ September 11, 2008: Message edited by: Ivan Koblik ]
Forgot to mention:

Saving is also done through HibernateTemplate (this.getHibernateTemplate().saveOrUpdate(anObject);)
Hi All,

Could you please help me out with a problem that keeps bothering me. I use Hibernate with spring transaction management and Oracle 10g database.

Hibernate is initialized the next way:

Basically I get ObjectNotFoundException each time when
1. one read-only transaction gets an entity,
2. then some another concurrent transaction removes the entity from the database right after,
3. then the first one tries to lazily initialize a set in the entity, and not being capable of finding already removed rows throws the exception.

1 and 3 are executed in the same transaction, it seems like I have Read-Committed strategy. But, Oracle's read-only transactions are always serializable, which means that nothing in the database should change in scope of the transaction.

I wrote a small test to prove that hibernate doesn't behave:

So log shows that transactions that began before database was changed still see the changes.

I spent quite a while trying to figure out the way to force hibernate to use oracle's read-only or serialized transactions but failed.

I even tried to set hibernate.connection.isolation to 8, still didn't help.

Would appreciate any help!
Thanks in advance.