-
1. Re: Two questions regarding 1.2.2 to 1.2.3
belaban Jun 10, 2005 1:39 PM (in response to soeren)In 1.2.3, running *without* transactions, we acquire the locks during a method call, and release them after the call returns.
If your locks are not released, then this is a bug, or you're not committing your transactions. Create a reproducable unit test and a JIRA case and attach it to the JIRA case. -
2. Re: Two questions regarding 1.2.2 to 1.2.3
soeren Jun 10, 2005 3:28 PM (in response to soeren)Hi Bela,
"bela@jboss.com" wrote:
In 1.2.3, running *without* transactions, we acquire the locks during a method call, and release them after the call returns.
Sorry to ask you for this detail: Default mode (as the zip from sourceforge comes) means "REPEATABLE_READ". This just means a locking strategy but not a transaction manager involved? Or does this involve some JBossCache-built-in t.m.? I'm a little confused as it looks like for me if the use of a transcation manager and the node locking level are not linked together in any way? Coming from a database background I know there's always a transaction manager somewhere, otherwise locking is quite not possible. I need to be clear with this as to reproduce a matching case eventually for this:"bela@jboss.com" wrote:
If your locks are not released, then this is a bug, or you're not committing your transactions. Create a reproducable unit test and a JIRA case and attach it to the JIRA case.
To commit a transaction I must use a transaction manager, correct? So I assume that the use of "REPEATABLE_READ" in fact involves a JBossCache provided transaction manager BUT THEN I should use something like " tx.begin()" and "tx.end()" around each "cache.put(node)" call? This is somewhat surprising me as in 1.2.2 I just coded a "cache.put(node)" without any transaction code. So probably I've missed something so far in our coding? E.g. the very short demo code in chapter 4 of http://docs.jboss.org/jbcache/current/TreeCache/html/ also doesn't involve any transactional code.
Currently we're using the - default setting - DummyTransactionManagerLookup as Transaction manager. Rereading the docs now it's not clear to me if this is suitable for an standalone (outside JBoss) application. We're planning to have some 6-10 clients here on different physical hosts and having REPEATABLE_READ would be nice but not necessary at all.
Thanks,
Soeren Gerlach -
3. Re: Two questions regarding 1.2.2 to 1.2.3
belaban Jun 10, 2005 5:31 PM (in response to soeren)Locking can be used separately from a TxManager.
If you have a TxManager *and* you started a TX, then all locks are held until the end of the TX.
If you didn't start a TX, or don't have a TxManager installed, the scope of the locks is per method call -
4. Re: Two questions regarding 1.2.2 to 1.2.3
soeren Jun 11, 2005 3:50 PM (in response to soeren)Hi Bela,
it took me quite some hours today to find the exact problem but finally I was able to reproduce it. I have compiled everything together in JBCACHE-192.
Best regards,
Soeren -
5. Re: Two questions regarding 1.2.2 to 1.2.3
belaban Jun 12, 2005 1:48 AM (in response to soeren)Thanks, I assigned it to 1.2.4 (next release) in JIRA.