Oracle数据库的TX锁

以前很讨厌Oracle数据库,做DML(insert/update/delete)操作还要commit,但深入理解Oracle数据库的锁机制后,才认识到Oracle数据库的优秀和commit/rollback的合理性。Oracle数据库对并发操作的支持做得非常好,但如果不合理利用,后果同样很严重。

Oracle数据库的锁粒度上分为表级锁和行级锁,但实际上通常考虑行级锁就可以了。表级锁应用在建立表,修改表结构,建立索引,删除表等操作上,这是重大操作,一般的后台不会提供这样的权限。因此本文只谈行级锁。

行级锁仅有一个锁类型,就是TX锁。TX锁的T代表transaction,表面上一个TX锁对应一条记录,但实际上整个DML操作无论做多少遍,只要没commit,加在记录上的TX锁状态就不会改变。X代表排斥(exclusive),表级锁X不允许没持有权限的session(会话)进行任何相关表(包括表中记录)的读和写操作,但TX锁允许没持有权限的session读取记录,这涉及到Oracle副本机制,实际上session读取到的是原始记录,而非副本中的修改记录。

TX锁权限的获得方法有:
1.DML操作(insert/update/delete)
2.使用SQL语句:select *** from TableName (where ***) for update nowait;
不要小看第二种方法。

session释放当前持有的全部TX锁权限的方法有:commit和rollback。commit是合并副本到本体,rollback是抛弃副本。

启动两个Oracle SQL Plus窗口,这将是两个不同的session,可以用来模拟两个客户的行为。用这两个窗口做下面的实验,将会得出一些重要的认识。

Oracle数据库的副本机制
1.表的操作create/drop不会产生副本,倘若操作成功,作用是立刻反映到本体上。因此create和drop操作事实上无需补上commit
session甲:
create table test(
id number(5) primary key,
value NVARCHAR2(10));
session乙:select * from test;

session乙没有错误产生。

session甲:drop table test;
session乙:select * from test;

session乙将发生错误。

重新在session甲创建test表,继续下面的实验。

Oracle数据库的sequence
Oracle中的主键不会自动递增,需要手动创建sequence,插入新记录时使用sequence的nextval
2.sequence和事务无关,不需要锁。
session甲:create sequence test_seq increment by 1 start with 1 maxvalue 99999;
session甲:commit;
session甲:insert into test values(test_seq.nextval, 'test');
session甲:select * from test;
ID VALUE
---------- --------------------
1 test
session乙:insert into test values(test_seq.nextval, 'test2');
session乙:select * from test;
ID VALUE
---------- --------------------
2 test2

session甲和session乙都commit后,select * from test的结果是
ID VALUE
---------- --------------------
1 test
2 test2

Oracle数据库的TX锁机制和副本机制
3.Oracle数据库的记录差异会保存到副本中(借用一下网游的名词),每个session对记录的修改都会产生各自的副本,只有在commit后,副本才会合并到本体中。
session乙:delete from test where id=2;
session乙:select * from test;
ID VALUE
---------- --------------------
1 test
session甲:select * from test;
ID VALUE
---------- --------------------
1 test
2 test2
session乙:commit;
session甲:select * from test;
ID VALUE
---------- --------------------
1 test

4.仅有差异化会保存到副本,也即只有持有TX权限的记录的修改结果会保存到副本。一个session commit后,差异化合并到本体,另外的session的select仍然会发生变化,也即session对记录的select是同时根据本体和当前持有的副本。
session乙:insert into test values(test_seq.nextval, 'test3');
session甲:update test set value='test111' where id=1;
session乙:select * from test;
ID VALUE
---------- --------------------
1 test
3 test3
session甲:commit;
session乙:select * from test;
ID VALUE
---------- --------------------
1 test111
3 test3
session甲:insert into test values(test_seq.nextval, 'test4');
session甲:commit;
session乙:select * from test;
ID VALUE
---------- --------------------
1 test111
3 test3
4 test4
session甲:select * from test;
ID VALUE
---------- --------------------
1 test111
4 test4
session乙:commit;
session甲:select * from test;
ID VALUE
---------- --------------------
1 test111
3 test3
4 test4

5.一个记录的TX权限被session乙取得后,session甲对这个记录的DML操作会进入等待状态,直到TX锁被释放,session甲才能获得这个记录的TX权限,这是Oracle数据库解决操作冲突的机制。
session乙:update test set value='test1' where id=1;
session甲:update test set value='test1111' where id=1;

session甲会进入等待状态
session乙:commit;
session甲会执行SQL语句(同时获得了TX锁权限)
session甲:commit;
session乙:delete from test where id=1;
session甲:update test set value='test' where id=1;

session甲会进入等待状态
session乙:commit;
session甲会执行SQL语句,但要修改的记录已经不存在,所以影响了0条记录
session甲:commit; (是否执行commit已经没所谓,但在商业程序中,在DML操作后一定要commit,不管是否记录数为0,DML操作如果失败,则执行rollback)

6.第5条中的DML操作包括insert,对存在primary key insert具有相同key值的记录,同样会产生TX权限冲突。
session乙:insert into test values(0, 'test0');
session甲:insert into test values(0, 'test000');

session甲会进入等待状态
session乙:commit;
session甲会执行SQL语句,但产生了错误
session甲:rollback;

7.程序设计不合理将会产生死锁
下面的操作请谨慎进行,余不负责解决导致的后果
session甲:update test set value='test33' where id=3;
session乙:update test set value='test44' where id=4;
session甲:update test set value='test444' where id=4;
session乙:update test set value='test333' where id=3;

因为都没执行commit,session甲和session乙都将进入等待对方释放锁权限的状态,是为死锁
终止这两个session都不能释放id=3和id=4这两条记录的锁状态,因为锁状态是保存在Oracle数据库的数据表中(请搜索Google大神解决也同时学习一下)

合理使用Oracle数据库的锁权限,解决锁冲突
因为DML操作是自动获得TX权限,很多人会被这表面蒙蔽,从而写程序时不留意导致死锁。
如何合理解决锁冲突?

8.不能滥用高等级锁
TX锁的粒度是单条记录,是粒度很细的锁,倘若如果觉得解决锁冲突很麻烦而使用高等级的锁,如表级锁X(X是完全排斥的锁,不允许没持有权限的session做任何操作),死锁是没有了,但这是滥用。越高级的锁,所影响的范围越大,虽然拿使用X来做比喻,但使用X是极端的行为,普通的后台管理严禁使用X锁,后台管理之间的完全排斥不说,前台比如一个购物系统,顾客就不能购买任何东西。

9.那是否应该在一条DML操作后立刻进行commit?
这还是不值得推荐的做法。因为DML/commit操作会在数据库服务器产生和注销副本,商业系统面临的并发数不是小数目,频繁产生和注销副本会加重服务器负担。

10.将DML操作缓存在本地程序内存中是一个很好的做法,批量执行之后才commit,可以节省服务器开销。

11.但缓存方法的执行时间间隔就算再小,如果并发度很高,还是有死锁的危险。因此后台管理程序应该提供终止长时间没响应的锁的功能。

12.如何在缓存方法的基础上彻底泯灭死锁的危险?答案就是使用select for update nowait;
for update nowait仅对select操作有效,DML无法使用for update nowait。虽然DML操作会自动申请TX锁,但倘若锁已经被别人获得,DML操作会进行等待状态,这是死锁的根源所在。在DML操作前,首先使用select *** from TableName (where ***) for update nowait申请TX权限,如果申请失败,会返回异常,不会进入等待状态,只要select语句中的where条件子句和DML的条件子句一样,就能保证所影响的记录范围不会扩大。使用try…catch…语句捕捉异常,可以确保事务执行的正确性。事实上select for update nowait如果成功,已经为session建立了相关记录的副本,这对服务器的开销影响不大,因为DML最终还是要使用副本中的这些记录。
注意:insert操作倘若可能造成冲突,比如第6条,在操作前也应当使用select for update nowait(session甲就不会进入等待状态),倘若没有冲突危险,比如使用sequence.nextval作为primary key的值,不需要在操作前select for update nowait。

最后请思考一下下面的问题(深入理解select for update nowait):
session甲:select * from test where id=4 for update nowait;
session乙:update test set value='test44' where id=4;

session乙仍然会进入等待状态。为什么?

3,147 次浏览 | 没有评论
2011年4月6日 | 归档于 技术

後楽園・二重橋 – 東京の桜

後楽園的樱花开得比较早,东京的樱花普遍要晚一周

后乐园的枝垂樱,但从花瓣构成来看这个品种应该接近染井吉野

近观

远观

后乐园的樱花其实不是很多,这应该还是染井吉野

染井吉野樱盛开时,刚开始是粉红色,然后越来越白,到极盛时全白,风过处花瓣飞舞,正所谓樱吹雪
染井吉野虽然花的构造简单,但胜在规模,别的樱花品种是没有开得这么疯狂的

7分咲く,远观一片绯红,还是挺好看的

这不知啥品种了

好像是一种水仙

那天接着去了皇居外苑

大手町高楼林立,包围着皇居

二重桥

樱田门

2,856 次浏览 | 没有评论
2011年4月2日 | 归档于 私语

青春18きっぷ

きっぷ(切符),票的意思

日本真是一个什么都来“放題”的国家,飲み放題、食べ放題,还有乗り放題,这青春18きっぷ就是24小时内任意乘坐JR(全国范围)普通列车的车票,共可使用5次,或5人同时使用,11500日元。每次的车费仅相当于2300日元。

东京坐到藤泽的普通车票要900多,坐到热海估计就要两千多了,坐到名古屋居然要6000多,相比起来青春18非常实惠了。
和同事聊起的时候,都基本在当学生时利用过青春18来周游日本。一是没钱,二是时间多。
同事还说起一个蹭特急(非新干线)列车的窍门,特急列车都是需要买指定席票(车上会查票),但仍然和普通列车停靠同样的站台,上车后就躲进厕所,停靠下一站时下来,就可以躲避查票XD(事实上在过青森海峡时,因为不开行普通列车,这一区间持青春18是允许坐特急的,这样的区间全日本只有两个)

明天利用它去名古屋,虽然只是坐6个小时,但2300日元比坐巴士的一半还要便宜,物超所值了

2,655 次浏览 | 没有评论
2011年3月4日 | 归档于 私语

居家攻略 – 广式皮蛋瘦肉粥

材料:白粥,瘦肉,皮蛋(这不是废话么
如果还要什么的,随便加吧,比如火腿,炸豆腐,蔬菜之类的
注意锅的大小,材料如果太多的话会拌不动的

第一次做的时候材料就放太多了

要点:
1、材料一定要切得很碎,否则会拌不动
2、要时刻用勺子搅拌,否则底部会煮焦
3、材料的加入先后顺序按容易煮熟的难易程度

第二次。这个色泽好诡异,果然还是材料放太多了么,但味道非常好(唔唔~余都可以去开粤菜馆了

炒菜的话……
中国同事的手艺

余的手艺(掩面)(虽然味道还可以啦

6,872 次浏览 | 9 条评论
2011年2月13日 | 归档于 私语
标签:

横滨掠影(元町中華街、みなとみらい21)

今天下午去了横滨,主要逛了下中华街和港未來21(みなとみらい21),港未來的夜景很有名,但没时间逗留到晚上
有个同事住在横滨,邀请余去玩说了几次,今天却没空。春节(日本叫旧正月)期间横滨有很多节目,但因为没案内,只能作罢
中华街的中国物产价格很坑爹,比新大久保的物产店贵很多

碰上踩高跷的关公(?)出游,接受游人的合影请求哦

关帝庙(里面居然有赛钱箱!)

路上遇到了很多可爱的狗

中华街的小吃很多,这家店的生意特别红火

横滨大世界

内部,灯笼很有气氛

Cotton Bear,卖熊公仔(手工缝制)的店,门口放着等身大的公仔,欢迎合影(唔唔~余也好想上前去抱一抱

天后宫(妈祖庙)

向海边方向走去

回过头来(这才是正门啊

又遇到狗狗,一黑一白,非常可爱

横滨港

海水好干净(天津、珠海不惭愧一下吗

遥望港未來

去港未來的路上回过头来一张

那是横滨的最高楼,横滨地标大厦

一个非常强悍的停车楼,车可以一层层的开上去

摩天轮,港未來的标志物之一

临港公园(臨港パーク),遥望对岸

拉近镜头看风车

拉近镜头看大桥

港未来的街景

去的时候是从东京坐东海道线,之后坐みなとみらい线到中华街
回来的时候直接みなとみらい线+东急东横线到涉谷,车票还便宜一点

2,916 次浏览 | 没有评论
2011年2月13日 | 归档于 私语

東京スカイツリー(東京天空樹)と浅草寺

不太想闷在家里于是出去走走
昨天下雪,今天下雨,好仆街的天气。明天按天气预报是天晴

结果去浅草寺(せんそうじ)附近转了一圈(在新年初诣的时候同事就已经介绍过了,只不过去了明治神宫)
从银座线浅草站出来,在吾妻桥就看到了建设中的东京天空树,为了拍张好点的照片,又前去溜达溜达

玩了下黑白模式。東武伊勢崎線跨越隅田川(可以到日光,余也要泡温泉呜呜

墨田区役所遥望天空树(東武鉄道出资建造)

这张拍得还勉强

浅草寺(供奉的是观世音),雷门

仲见世通(雷门参道),非常热闹

主殿

五重塔

这鲤鱼太肥了

浅草神社,供奉的是浅草寺的三位创始人,现在和寺庙独立,为不同的财团法人管理

相比浅草寺的热闹,挺冷清的

絵馬(えま),幸运星的高良みゆきOrz

挺诡异的佛像

在浅草寺买的人形焼(にんぎょうやき),很好吃~

3,183 次浏览 | 没有评论
2011年2月12日 | 归档于 私语

UniCue 1.3beta6 – 一个编码转换工具

名字来由:Uni代表Unicode,Cue为cuesheet,意为将各种编码的cue文件转换到unicode编码
本意是写一个foobar2000的插件实现编码的转换,但最后变成一堆杂七杂八程序的集合

项目开源,放在Github上托管
https://github.com/kuyur/unicue

目前包括的程序有:
Unicue(主要的编码转换工具)
Unicue Traveller(批量转换工具)
ChineseConverter(简繁繁简转换程序)
Traveller Ext(将Traveller注册到右键菜单的系统扩展)
ExtractAkaiito(PS2游戏アカイイト游戏脚本提取,不提供二进制程序,需自行编译)

各转换工具使用到的编码转换通用库(c4-lib)以及制作字符映射表的工程地址为
https://github.com/kuyur/c4

Unicue最新版本为1.3 beta6。
程序下载地址:
http://kuyur.github.io/unicue/Unicue_1.3beta6.zip
http://go.kuyur.info/Unicue_1.3beta6.zip

bug反馈或特性提出可直接在blog回复或前往https://github.com/kuyur/unicue/issues

Unicue Traveller使用注意事项:

  • 自动检测得到的编码还不能更改,因此有可能会使用错误的编码进行转换
  • 因此不建议覆盖而不备份
  • 目前手动更改选中状态还是会被无视
  • 卸载Unicue Traveller扩展菜单后,需要杀掉explorer.exe进程并重新启动explorer (或者简单地,重启系统) 才能移动或删除TravellerExt.dll文件

Unicue Traveller使用里・注意事项:

更新日志:

Unicue

1.3

  • 增加拉丁文字母支持(CP1252)
  • 一键转换
  • 可调整界面大小
  • 记忆最后使用的界面大小
  • 修正Linux平台下通过Wine运行时菜单不能正常显示的问题
  • 支持Ctrl+A快捷键

1.2

  • 允许选择输出编码(UTF-8/UTF-8无BOM/UTF-16LE/UTF-16BE)
  • 增强CUE文件的自动修正功能
  • 修正Win7以上版本在某种情况下注册到右键菜单却没有生效的Bug
  • 修正GBK映射表中欧元符号没有正确转换的Bug
  • 使用WTL取代MFC,静态编译解决库依赖问题(传说不需要任何第三方dll)
  • 更换新名字 (ANSI2Unicode -> Unicue)
  • 多语言界面 (简中,繁中,英,日)
    1. 感谢小海对繁体中文界面提出的修改建议/Thanks for 小海’s suggestions about Traditional Chinese GUI
    2. 感谢lemphek对英文界面提出的修改建议/Thanks for lemphek’s suggestions about English GUI
  • 增加西里尔字母支持(CP1251),涵括斯拉夫语族包括俄语,塞尔维亚语,保加利亚语等一大堆乱七八糟的语言
  • Linux平台下通过Wine(1.4.1)能稳定运行(菜单不能正常显示)

1.1

注: 1.1以前版本程序名字为Ansi2Unicode

  • 移除自身的转换函数
  • 使用c4-lib通用字符转换环境
  • 支持用户添加自定义字符映射表并设定转换规则
  • 修正图标

1.0.3

  • 完整的Unicode支持,不必为文档路径中的特殊字符担心
  • 修复Unicode补不完计划造成的丢字问题
    –内建基于UAO 2.50的Big5→Unicode字符映射表
    –Big5→Unicode单向转换,解决没有安装Unicode补完计划的win平台上显示Big5文档时的字符(日文假名/日文汉字/简体汉字)丢失问题
  • 转换结果保存为utf-8编码的文本
  • 自动检测文本编码
  • 支持文件拖放操作及命令行打开文档
  • 自动修正cue中的File行音频文件扩展名
  • 自动修正cue中的File行旧式“The True Audio”标签为“WAVE”
  • 不改变默认打开程序的txt/log/cue右键菜单关联
  • 提取tak/flac/ape的内嵌cue,并自动修正cue中的音频文件名
  • 转换字符串功能
  • 转换字符串模式下,支持拖放乱码文件名进行转换

Unicue Traveller

1.2

  • 基于WTL,无需安装任何运行库
  • 完整的Unicode支持
  • 修复Unicode补不完计划造成的丢字问题
  • 转换结果保存为utf-8编码的文本
  • 自动检测文本编码
  • 自动修正cue中的File行音频文件名
  • 自动修正cue中的File行旧式“The True Audio”标签为“WAVE”
  • 批量修改文本文件
    1. 任意的文件夹和文件组合的右键菜单
    2. 文件夹的空白菜单
  • 可指定文件类型
  • 两种保存方式
    1. 覆盖(备份可选)
    2. 另存为(可指定命名模板)

Chinese Converter

1.3

  • 保存配置
  • 可调整窗口大小并记忆最后使用的窗口尺寸
  • 添加菜单
  • 添加覆盖文件的保存按钮

1.2

  • 支持Unicode LE/BE以及UTF-8格式的文本读取和写入
  • 停止使用MFC,转用WTL并静态编译(传说无需任何第三方dll)
  • 更换图标
  • Linux平台下通过Wine(1.4.1)能稳定运行

1.0

  • 简繁繁简转换
  • 仅支持Unicode(LE)输入和Unicode(LE)保存转换结果
  • 采用维基简繁繁简一对一映射表,如有问题找维基
  • 不支持词组转换

开发Unicue的历史缘由

IE转换Unicode补完计划下创建的Big5文本会造成日文假名字符丢失(所有调用win32 api函数MultiByteToWideChar的转换程序都有此问题,原因是Unicode补完计划动用了Big5的自定义造字区,但并非所有人都会去安装Unicode补完计划,在没有安装Unicode补完计划的win平台的CP950中,这些字符是没有定义的)

于是使用自定义的映射表b2u-little-endian.map及自定义的转换函数,绕过CP950以及MultiByteToWideChar

Ansi2Unicode 1.0.3 简明Readme:

选项说明
选项会从配置文件Config.xml读取,如果配置文件不存在或解析错误,会重新生成配置文件

另存文件的命名模板:填写随意,如果留空,则会覆盖原来的文件

自动修正cue文件中的音频扩展名:勾选会依据cue中的音频文件名(不含扩展名)去查找同目录下的音频档案来自动修正cue文件,同时“替换cue文件FILE行的The True Audio为WAVE”会默认生效(无论此选项是否勾选)

提取音频文档(flac/tak/ape)的内嵌cue:勾选后在打开flac/tak/ape文件会提取内嵌cue,否则会视为文本文件打开

注册右键菜单关联:会写如下注册表项

HKEY_CLASSES_ROOT\.uni
@=”UniCue.UNI”

HKEY_CLASSES_ROOT\UniCue.UNI
@=”UniCue 文件”

HKEY_CLASSES_ROOT\UniCue.UNI\shell
@=”Open”

HKEY_CLASSES_ROOT\UniCue.UNI\shell\Open
@=”使用 UniCue 打开”

‘AppPathName为程序路径,如E:\\Program Files (x86)\\UniCue\\Ansi2Unicode.exe
HKEY_CLASSES_ROOT\UniCue.UNI\shell\Open\command
@=”\”AppPathName\” \”%1\””

HKEY_CLASSES_ROOT\UniCue.UNI\shell\unicue
@=”使用 UniCue 转换编码”

HKEY_CLASSES_ROOT\UniCue.UNI\shell\unicue\command
@=”\”AppPathName\” \”%1\””

HKEY_CLASSES_ROOT\txtfile\shell\unicue
@=”使用 UniCue 转换编码”

HKEY_CLASSES_ROOT\txtfile\shell\unicue\command
@=”\”AppPathName\” \”%1\””

‘程序会查找cue文件的注册表信息,假定cue已经关联到foobar2000.CUE
‘如果cue文件类型的信息不存在,会将cue关联到UniCue.UNI
HKEY_CLASSES_ROOT\foobar2000.CUE\shell\unicue
@=”使用 UniCue 转换编码”

HKEY_CLASSES_ROOT\foobar2000.CUE\shell\unicue\command
@=”\”AppPathName\” \”%1\””

HKEY_CLASSES_ROOT\Applications\notepad.exe\shell\unicue
@=”使用 UniCue 转换编码”

HKEY_CLASSES_ROOT\Applications\notepad.exe\shell\unicue\command
@=”\”AppPathName\” \”%1\””

HKEY_CLASSES_ROOT\Applications\ANSI2Unicode.exe\shell\open\command
@=”\”AppPathName\” \”%1\””

‘AppFolder为程序目录,如E:\\Program Files (x86)\\UniCue
HKEY_CLASSES_ROOT\UniCue.UNI\DefaultIcon
@=”AppFolder\\icons\\file.ico”

简单的说,在cue文件已经被关联到某种程序(例如foobar2000)的情况下,会在cue文件的右键菜单添加“使用 UniCue 转换编码”
如果cue文件默认打开方式还不存在,则默认打开方式会变更为ANSI2Unicode.exe
会在txt/log类型的文件(实际上为记事本notepad.exe的关联文件类型)的右键菜单添加“使用 UniCue 转换编码”的选项

卸载右键菜单:还原为原来的状态

新建utf-8编码的文本文件:会更改如下注册表项

删除HKEY_CLASSES_ROOT\.txt\ShellNew下的 NullFile 键值

写键值:(AppFolder为程序所在目录)
HKEY_CLASSES_ROOT\.txt\ShellNew
“FileName”=”AppFolder\\null.uni”

在新建文本文件时会使用utf-8类型的空白模板,编辑此txt文档时直接ctrl+s即可,无需另存为时选择utf-8

还原为默认的新建文本文档:还原为原始状态

转换文件编码的方法
1.启动程序,拖曳文本文件到程序窗体释放
2.启动程序,从菜单打开
3.在注册右键菜单关联后,从右键菜单选择“使用 UniCue 转换编码”
4.命令行窗口:命令行方式(第三方工具可通过此方法传递参数调用Ansi2Unicode)

E:\Program Files (x86)\UniCue>ansi2unicode “F:\downloads\EAC\[EAC][110126]真理絵
_Works_Best_II「Sing_Up!」(wav+cue)\Sing Up.cue”

转换乱码文本或乱码文件名的方法
切换到“转换字符串”模式,拖曳文件(支持多个文件)到程序窗体释放,或者直接在左边窗体粘贴乱码文本,点击按钮“>>”
(不会自动替换原来的乱码文件名)

使用技巧
在使用ANSI2Unicode打开一次文件之后,可以从右键菜单的“打开方式”快速使用ANSI2Unicode打开

相关博文:

tinyXml输出utf-8文档
一个线性时间复杂度的字符编码转换算法
UTF-8到Unicode的转换以及UTF-8编码的检测
GBK、Shift-JIS、BIG5编码检测算法
アカイイト 游戏脚本文件分析及脚本提取
tinyXml处理UTF-8编码详解——写入和读取
tak的内嵌cue提取
flac的内嵌cue提取
动态加载字符映射表的字符转换环境方案

12,806 次浏览 | 7 条评论
2011年2月12日 | 归档于 作品, 程序

新年初詣(はつもうで)

一宿没睡。白天在C79战了一天,晚上又熬了一夜,真应该12点就去明治神宫参拜然后回去睡觉好了

早上7点多到达JR代代木站,前往明治神宫,7点45分已经又返回代代木站,三十多分钟就结束了新年初詣

早上比较冷,人还是不多的。卖炒面、章鱼烧等的店都还没开张

围了起来只能往池子里投钱,坑爹啊,余要摇绳啊~

北参道方向的高楼,但好像不是东京都厅

2,601 次浏览 | 没有评论
2011年1月1日 | 归档于 私语
标签: ,

【C79】今天败的CD

本来今天不大想去的,结果为了给z叔补回魂音泉,决定还是去了
到最后却收不了手,直到钱包快没钱,总结发现去Comiket不想花太多钱的最好做法就是不要带那么多现金(掩面
第一次为原作者交版权费

早上7点起床,8点半去到会场,早已经人山人海。10点多进入会场,立刻往东区移动
去到东区时刚开始即使是热门团体,队伍也还不算太长的。于是迅速移动败了一些CD
接着去排片雾,队伍已经有一定长度。见到了片雾,非常元気
旁边就是miko,于是也见到了真人
龙骑士的队伍很恐怖,对游戏前作都没推,果断放弃
去买志芳的碟时已经sold out,算是小遗憾之一。由于没见过志芳照片,因此不知道是否本人(非本人的可能性大一点

和很多人说了同事前天刚教的ようようとしよう(再掩面

感谢风筝酱提供大量有效信息

又清了一遍昨天+今天的碟,发现是32张。C-CLAYS的两张是旧碟,自己被自己坑了,新谱居然没买到

给桃子买了3张,给z叔买了1张,这一摞中共4张重复
C79-CD

C79-CD

C79-CD

C79-CD

六弦alice送了好多东西,两个文件夹+两张明信片
Primary(yuiko)、encounter+和ALLEGORY WORKS三张联售,袋子里居然还有一颗糖果呜
叶月的送了一张贴纸
C79-CD

今天不想拍cos了。去企业馆逛了两圈,好在余不控着仆街周边
规定是不允许拍照,但很多人拿着手机和小相机在拍,事实上没那么严格
风筝要拍的勇者圣衣还是没找到Orz

3,445 次浏览 | 没有评论
2010年12月31日 | 归档于 私语
标签: , ,

【C79】痛車とコスプレ

不要问余为神马基本都过曝了
掩面

不想码字。明天也不知还去不去

C79

C79

C79

C79

下午去拍痛车,这停车场靠近临海线的東京テレポート站
C79

C79

C79

C79

C79

C79

C79

C79

C79

C79

C79

C79

C79

C79

C79

C79

C79

C79

cosplay慎入
阅读全文…

3,217 次浏览 | 没有评论
2010年12月30日 | 归档于 私语
标签: , ,