 |
AppletTalk.com Java discussions newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Maciej Guest
|
Posted: Wed Oct 18, 2006 7:21 pm Post subject: Locks and transactions |
|
|
Hi,
I have some newbie's questions. I use some applications where there are
two techniques handling with concurrent access do DB:
- Multi-Read-Single-Write Lock
- transactions based on JDBC
After comparision of these solutions I have a few questions:
1. If I put a WRITE lock on a single table, no other can read or write
this table, isn't ?
2. When I put a READ lcok on a single table, no other can write to this
table, but others can read it, isn't ?
3. If I start to transactions on the same table, one during another,
what happends when the second one finishes before first what happens?
4. Is my understanding is correct, that locks are safer but could block
access to the table during concurrent access, whether transaction no?
Thank you in advance,
Maciej |
|
| Back to top |
|
 |
joeNOSPAM@BEA.com Guest
|
Posted: Wed Oct 18, 2006 7:33 pm Post subject: Re: Locks and transactions |
|
|
On Oct 18, 7:21 am, "Maciej" <mgawine...@gmail.com> wrote:
| Quote: | Hi,
I have some newbie's questions. I use some applications where there are
two techniques handling with concurrent access do DB:
- Multi-Read-Single-Write Lock
- transactions based on JDBC
After comparision of these solutions I have a few questions:
1. If I put a WRITE lock on a single table, no other can read or write
this table, isn't ?
2. When I put a READ lcok on a single table, no other can write to this
table, but others can read it, isn't ?
3. If I start to transactions on the same table, one during another,
what happends when the second one finishes before first what happens?
4. Is my understanding is correct, that locks are safer but could block
access to the table during concurrent access, whether transaction no?
Thank you in advance,
Maciej
|
Hi. In the real world you have to become very familiar with
how a given brand of DBMS does it's locking. There are
some significant differences that make generalities useless.
For instance, it takes some non-standard SQL to get Oracle
to block other transactions from reading data.
If you want to do this right, you have to dig into the DBMS
documentation about locking and transactional concurrency,
and then your application will work with *that* DBMS. Converting
to run with a second type of DBMS will *not* be trivial.
Good luck,
Joe Weinstein at BEA Systems |
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|