~mysql/mysql-server/mysql-6.0

« back to all changes in this revision

Viewing changes to mysql-test/include/concurrent.inc

  • Committer: Alexander Nozdrin
  • Date: 2009-04-24 10:04:14 UTC
  • mfrom: (2651.1.45 mysql-6.0)
  • Revision ID: alik@sun.com-20090424100414-92m55kfywauveb56
PullĀ fromĀ 6.0

Show diffs side-by-side

added added

removed removed

Lines of Context:
11
11
#   $engine_type                     storage engine to be tested
12
12
#
13
13
# Last update:
 
14
# 2009-02-13 HH "Release_lock("hello")" is now also successful when delivering NULL,
 
15
#               replaced two sleeps by wait_condition. The last two "sleep 1" have not been
 
16
#               replaced as all tried wait conditions leaded to nondeterministic results, especially
 
17
#               to succeeding concurrent updates. To replace the sleeps there should be some time
 
18
#               planned (or internal knowledge of the server may help).
14
19
# 2006-08-02 ML test refactored
15
20
#               old name was t/innodb_concurrent.test
16
21
#               main code went into include/concurrent.inc
20
25
#               new wrapper t/concurrent_innodb_safelog.test
21
26
#
22
27
 
 
28
--source include/not_embedded.inc
 
29
 
23
30
connection default;
24
 
 
25
31
#
26
32
# Show prerequisites for this test.
27
33
#
50
56
#
51
57
# Preparatory cleanup.
52
58
#
53
 
DO release_lock("hello");
54
 
DO release_lock("hello2");
55
59
--disable_warnings
56
60
drop table if exists t1;
57
61
--enable_warnings
86
90
      connection thread2;
87
91
      --echo ** Start transaction for thread 2
88
92
      begin;
89
 
      --echo ** Update will cause a table scan and a new ULL  will 
 
93
      --echo ** Update will cause a table scan and a new ULL  will
90
94
      --echo ** be created and blocked on the first row where tipo=11.
91
95
      send update t1 set eta=1+get_lock("hello",10)*0 where tipo=11;
92
 
      sleep 1;
93
96
 
94
97
  --echo ** connection thread1
95
98
  connection thread1;
 
99
  let $wait_condition= select count(*)= 1 from information_schema.processlist where state= 'User lock';
 
100
  --source include/wait_condition.inc
96
101
  --echo ** Start new transaction for thread 1
97
102
  begin;
98
103
  --echo ** Update on t1 will cause a table scan which will be blocked because
111
116
  }
112
117
  --echo ** Release user level name lock from thread 1. This will cause the ULL
113
118
  --echo ** on thread 2 to end its wait.
114
 
  select release_lock("hello");
 
119
# Due to Bug#32782 User lock hash fails to find lock, which probably also cause Bug#39484 (main.concurrent_innodb_safelog fails sporadically) the success of the following
 
120
# is also guaranteed for NULL. Replaced SELECT by DO (no result).
 
121
  DO release_lock("hello");
115
122
  --echo ** Table is now updated with a new eta on tipo=22 for thread 1.
116
123
  select * from t1;
117
124
 
119
126
      connection thread2;
120
127
      --echo ** Release the lock and collect result from update on thread 2
121
128
      reap;
122
 
      select release_lock("hello");
 
129
# Due to Bug#32782 User lock hash fails to find lock, which probably also cause Bug#39484 (main.concurrent_innodb_safelog fails sporadically) the success of the following
 
130
# is also guaranteed for NULL. Replaced SELECT by DO (no result).
 
131
      DO release_lock("hello");
123
132
      --echo ** Table should have eta updates where tipo=11 but updates made by
124
133
      --echo ** thread 1 shouldn't be visible yet.
125
134
      select * from t1;
183
192
      --echo ** This will cause a hang on the first row where tipo=1 until the
184
193
      --echo ** blocking ULL is released.
185
194
      send update t1 set eta=1+get_lock("hello",10)*0 where tipo=1;
186
 
      sleep 1;
187
195
 
188
 
  --echo ** connection thread1
 
196
--echo ** connection thread1
189
197
  connection thread1;
 
198
  let $wait_condition= select count(*)= 1 from information_schema.processlist where state= 'User lock';
 
199
  --source include/wait_condition.inc
190
200
  --echo ** Start transaction on thread 1
191
201
  begin;
192
202
  --echo ** Update on t1 will cause a table scan which will be blocked because
204
214
    update t1 set tipo=1 where tipo=2;
205
215
  }
206
216
  --echo ** Release ULL. This will release the next waiting ULL on thread 2.
207
 
  select release_lock("hello");
 
217
# Due to Bug#32782 User lock hash fails to find lock, which probably also cause Bug#39484 (main.concurrent_innodb_safelog fails sporadically)the success of the following
 
218
# is also guaranteed for NULL. Replaced SELECT by DO (no result).
 
219
  DO release_lock("hello");
208
220
  --echo ** The table should still be updated with updates for thread 1 only:
209
221
  select * from t1;
210
222
 
212
224
      connection thread2;
213
225
      --echo ** Release the lock and collect result from thread 2:
214
226
      reap;
215
 
      select release_lock("hello");
 
227
# Due to Bug#32782 User lock hash fails to find lock, which probably also cause Bug#39484 (main.concurrent_innodb_safelog fails sporadically) the success of the following
 
228
# is also guaranteed for NULL. Replaced SELECT by DO (no result).
 
229
      DO release_lock("hello");
216
230
      --echo ** Seen from thread 2 the table should have been updated on four
217
231
      --echo ** places.
218
232
      select * from t1;
264
278
      --echo ** Update will create a table scan which creates a ULL where a=2;
265
279
      --echo ** this will hang waiting on thread 1.
266
280
      send update t1 set b=10+get_lock(concat("hello",a),10)*0 where a=2;
267
 
      sleep 1;
268
281
 
269
282
  --echo ** connection thread1
270
283
  connection thread1;
 
284
  let $wait_condition= select count(*)= 1 from information_schema.processlist where state= 'User lock';
 
285
  --source include/wait_condition.inc
271
286
  --echo ** Insert new values to t1 from thread 1; this created an implicit
272
287
  --echo ** commit since there are no on-going transactions.
273
288
  insert into t1 values (1,1);
274
289
  --echo ** Release the ULL (thread 2 updates will finish).
275
 
  select release_lock("hello2");
 
290
# Due to Bug#32782 User lock hash fails to find lock, which probably also cause Bug#39484 (main.concurrent_innodb_safelog fails sporadically) the success of the following
 
291
# is also guaranteed for NULL. Replaced SELECT by DO (no result).
 
292
  DO release_lock("hello2");
276
293
  --echo ** ..but thread 1 will still see t1 as if nothing has happend:
277
294
  select * from t1;
278
295
 
280
297
      connection thread2;
281
298
      --echo ** Collect results from thread 2 and release the lock.
282
299
      reap;
283
 
      select release_lock("hello2");
 
300
# Due to Bug#32782 User lock hash fails to find lock, which probably also cause Bug#39484 (main.concurrent_innodb_safelog fails sporadically) the success of the following
 
301
# is also guaranteed for NULL. Replaced SELECT by DO (no result).
 
302
      DO release_lock("hello2");
284
303
      --echo ** The table should look like the original+updates for thread 2,
285
304
      --echo ** and consist of new rows:
286
305
      select * from t1;
534
553
      connection thread2;
535
554
      begin;
536
555
      send delete from t1 where tipo=2;
 
556
# The sleep has not been replaced as all tried wait conditions leaded to sporadically
 
557
# succeding update in the following thread. Also the used status variables '%lock%' and
 
558
# 'innodb_deleted_rows' and infos in processlist where not sucessful.
537
559
      sleep 1;
538
560
 
539
561
  --echo ** connection thread1
594
616
      connection thread2;
595
617
      begin;
596
618
      send delete from t1 where tipo=2;
 
619
# The sleep has not been replaced as all tried wait conditions leaded to sporadically
 
620
# succeding update in the following thread. Also the used status variables '%lock%' and
 
621
# 'innodb_deleted_rows' and infos in processlist where not sucessful.
597
622
      sleep 1;
598
 
  
 
623
 
599
624
  --echo ** connection thread1
600
625
  connection thread1;
601
626
  begin;