Subject | Re: [ib-support] Serialization? |
---|---|
Author | Matteo Giacomazzi |
Post date | 2002-07-06T06:50:09Z |
Hi Raul,
Saturday, July 06, 2002, you wrote:
RC> How about this scheme:
RC> Create a table, let's say, ACTIVE_HOSTS:
RC> create table ACTIVE_HOSTS (
RC> host_ip varchar(16), /* or some other thing to identify a host */
RC> primary key (host_ip)
RC> );
RC> and the first thing a download thread does is to start a
RC> transaction, let's call it "TRANS1", and tries to insert a the
RC> host_ip in ACTIVE_HOSTS table using "TRANS1". This insert will
RC> fail if another thread is working on the same host (you'll see
RC> later why). Obvious, if the insert fails thread stops or waits, if
RC> not it starts another transaction, let's call it "TRANS2", do the
RC> work using "TRANS2" and, finally, commits "TRANS2" and ROLLBACK
RC> !!! the "TRANS1".
RC> The ideea is that the insert into ACTIVE_HOSTS fails if another
RC> thread inserted that host before even it didn't commited. The
RC> "TRANS1" must be kept active untill the thread is done with that
RC> host and after that (this is the key part) it rollsback "TRANS1"
RC> so the inserted row will disapear making possible for another
RC> thread to start download from that host.
RC> Another ideea is to start "TRANS1" with "isc_tpb_wait" parameter
RC> so an insert in ACTIVE_HOSTS will wait if/untill another thread is
RC> done (rollsback it's "TRANS1").
RC> If you like it, try it ! I'm not very sure this will work (I
RC> didn't test it), but is very probable !
Yup, it's a very interesting idea!
But I wonder if it isn't a "bad thing" to build up a "procedure" on
ROLLBACKs...
Maybe, instead of ROLLBACK i could DELETE the row just inserted?
I mean ():
SET TRANSACTION NAME TRANS_1 [...]
INSERT INTO ACTIVE_HOST (HOST_ID) [...]
SET TRANSACTION NAME TRANS_2 [...]
[...download the document...]
COMMIT TRANS_2;
DELETE FROM ACTIVE_HOST
WHERE HOST_ID = 'whatever';
COMMIT TRANS_1;
It should work too.
But, really, I don't like too much to keep a transaction opened for a
so long time...
I will think a little more about something else, but this one seems to
be the right way.
Thank you!
Kind regards,
--
Matteo
mailto:matteo.giacomazzi@...
ICQ# 24075529
Saturday, July 06, 2002, you wrote:
RC> How about this scheme:
RC> Create a table, let's say, ACTIVE_HOSTS:
RC> create table ACTIVE_HOSTS (
RC> host_ip varchar(16), /* or some other thing to identify a host */
RC> primary key (host_ip)
RC> );
RC> and the first thing a download thread does is to start a
RC> transaction, let's call it "TRANS1", and tries to insert a the
RC> host_ip in ACTIVE_HOSTS table using "TRANS1". This insert will
RC> fail if another thread is working on the same host (you'll see
RC> later why). Obvious, if the insert fails thread stops or waits, if
RC> not it starts another transaction, let's call it "TRANS2", do the
RC> work using "TRANS2" and, finally, commits "TRANS2" and ROLLBACK
RC> !!! the "TRANS1".
RC> The ideea is that the insert into ACTIVE_HOSTS fails if another
RC> thread inserted that host before even it didn't commited. The
RC> "TRANS1" must be kept active untill the thread is done with that
RC> host and after that (this is the key part) it rollsback "TRANS1"
RC> so the inserted row will disapear making possible for another
RC> thread to start download from that host.
RC> Another ideea is to start "TRANS1" with "isc_tpb_wait" parameter
RC> so an insert in ACTIVE_HOSTS will wait if/untill another thread is
RC> done (rollsback it's "TRANS1").
RC> If you like it, try it ! I'm not very sure this will work (I
RC> didn't test it), but is very probable !
Yup, it's a very interesting idea!
But I wonder if it isn't a "bad thing" to build up a "procedure" on
ROLLBACKs...
Maybe, instead of ROLLBACK i could DELETE the row just inserted?
I mean ():
SET TRANSACTION NAME TRANS_1 [...]
INSERT INTO ACTIVE_HOST (HOST_ID) [...]
SET TRANSACTION NAME TRANS_2 [...]
[...download the document...]
COMMIT TRANS_2;
DELETE FROM ACTIVE_HOST
WHERE HOST_ID = 'whatever';
COMMIT TRANS_1;
It should work too.
But, really, I don't like too much to keep a transaction opened for a
so long time...
I will think a little more about something else, but this one seems to
be the right way.
Thank you!
Kind regards,
--
Matteo
mailto:matteo.giacomazzi@...
ICQ# 24075529