On Jan 15, 2008 12:03 AM, Adam Rich <[EMAIL PROTECTED]> wrote:
> > Advisory locks would work here (better that than table lock), but I
> > don't think that's the right approach. Transaction 2 should simply do
> > a
> > select * from parent_tbl
> > where id=1 for update;
> >
> > at the start of the
> Advisory locks would work here (better that than table lock), but I
> don't think that's the right approach. Transaction 2 should simply do
> a
> select * from parent_tbl
> where id=1 for update;
>
> at the start of the transaction.
That's actually what I'm doing (just forgot to include it in
On Jan 14, 2008 5:57 PM, Adam Rich <[EMAIL PROTECTED]> wrote:
> >
> > From what I can tell, this kind of roll-your-own application level
> > locking system is exactly what advisory locks are for. Search the
> > archives for the last couple of weeks as I remember someone posting
> > some really he
On Jan 14, 2008 4:31 PM, Adam Rich <[EMAIL PROTECTED]> wrote:
> > You should be able to do "select for update" on both parent and child
> > records and get the effect you desire.
> >
>
> I don't think that will work. Let me demonstrate:
> (this is simplified, but sufficient to make my point)
>
> -
On Jan 14, 2008, at 4:57 PM, Adam Rich wrote:
From what I can tell, this kind of roll-your-own application level
locking system is exactly what advisory locks are for. Search the
archives for the last couple of weeks as I remember someone posting
some really helpful functions to assist in us
>
> From what I can tell, this kind of roll-your-own application level
> locking system is exactly what advisory locks are for. Search the
> archives for the last couple of weeks as I remember someone posting
> some really helpful functions to assist in using advisory locks.
>
> Erik Jones
Yes
On Jan 14, 2008, at 3:54 PM, andy wrote:
In our program we wrote the locking into the program, and created a
modulelock table like:
create table moduelock(
userid int,
module int,
primary key (userid, module)
)
The program then locks things before it uses them... but we also
have pr
Adam Rich wrote:
I have a "parent_tbl" and dozens of data tables, with foreign keys
referencing the PK of "parent_tbl" (one-to-many). There are 100+
users accessing the application, usually (but not always) each user
is working on a different record in parent_tbl. (this would seem like a pret
On Jan 14, 2008 3:31 PM, Adam Rich <[EMAIL PROTECTED]> wrote:
> > You should be able to do "select for update" on both parent and child
> > records and get the effect you desire.
> >
>
> I don't think that will work. Let me demonstrate:
> (this is simplified, but sufficient to make my point)
>
> -
> You should be able to do "select for update" on both parent and child
> records and get the effect you desire.
>
I don't think that will work. Let me demonstrate:
(this is simplified, but sufficient to make my point)
-- Connection 1 --
begin trans;
select * from parent_tbl
where id=1 for upda
On Jan 14, 2008 2:43 PM, Adam Rich <[EMAIL PROTECTED]> wrote:
>
> I have a "parent_tbl" and dozens of data tables, with foreign keys
> referencing the PK of "parent_tbl" (one-to-many). There are 100+
> users accessing the application, usually (but not always) each user
> is working on a different
I have a "parent_tbl" and dozens of data tables, with foreign keys
referencing the PK of "parent_tbl" (one-to-many). There are 100+
users accessing the application, usually (but not always) each user
is working on a different record in parent_tbl. (this would seem like a pretty
standard scena
12 matches
Mail list logo
