yamicha.com's Blog - Presented by yamicha.com
Blog yamicha.com's Blog - 2018/01 の記事
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31]

yamicha.com's Blog
 諸事情により、現在更新休止中。ご了承ください。もし今後ブログを再開することがあるとすれば、その際にはこのブログスクリプトではなく、新しく開発したものによるかもしれません。
 当ブログ管理者についてはこちらをご参照。
開発魔法(737)
社会問題(733)
お知らせ(11)
質問・バトン回答(15)
ゲスト出演(8)
経済・知的財産(150)
ゲーム開発(182)
[Ada] 勝手に補足
- Note
- 金配りの次の一手


- Endless Ultimate Diary
- 銃世界

漢字バトン
- うるる雑記帳
- 漢字接力棒

ツキアイゲノムバトン
- ブログ@うにうに画像倉庫
- あぶ内閣

縺イ縺セ縺、縺カ縺励ヰ繝医Φ
- 月夜のボヤキ
- 騎士サーラバトン
パスワードを使う
名無し (2012/02/27)


開発者解放裁判
yamicha.com (2010/03/14)
Winnyに関しては、私も「純白」とまでは考えておりませんし、使用し..

開発者解放裁判
通りすがり (2010/03/08)
winnyに関しては「ダウンロードソフト板」なんてところを拠点に開発..

新型インフルエンザの恐怖
いげ太 (2009/11/03)
> C#などの「int Some(int , int)」は、F#では「(int * int) ->..

時効に関する思考
yamicha.com (2009/08/31)
>いげ太さんコメントありがとうございます。手元にドキュメントが少..
Homepage
Blog Top
Normal View
List View
Search
Calendar
Comment List
Trackback List
Blog RSS
Send Trackback
Phone Mode
Administrator
yamicha.com
Blog
るううるる。
Source
法令データ提供システム
FindLaw
Development
Java2 Platform SE 6
Java EE 6 API
MySQL Developer Zone
PHP Reference
MSDN Library
Ada Reference Manual
Objective Caml
Python Documentation
Erlang
Prolog Documents
X度目の正直の夫婦別姓
2010/01/12(Tue)02:04:56
 通常国会への提出が予定されている、夫婦別姓その他の制度に関する改正案の概要が明らかになりました。提出までに案が修正されないとは限らず、また連立の意向によっては提出を断念せざるを得なくなる可能性も残されているとはいえ、少なくとも夫婦別姓制度は十分に現実味を帯びてきたといえるでしょう。同案では主に以下のような点を改正するものとしています。
  1. 夫婦同姓は残しつつ、夫婦別姓を選択可能にする。ただし、夫婦別姓であっても子どもは全員同姓とする。
  2. 結婚可能な年齢を男女ともに18歳に統一。
  3. 女性が離婚後、再婚できない期間を100日に短縮。
  4. 非嫡出子の法定相続分差別をなくす。
 このうち2の結婚年齢の統一については、これといった反対意見はなさそうです。現行の結婚年齢は以下のように定められていますが、
(婚姻適齢)
第七百三十一条
男は、十八歳に、女は、十六歳にならなければ、婚姻をすることができない。
 そもそも明らかに非合理的な規定ですので、残しておく理由が全く存在しません。残る問題は、男女とも16歳に統一するか、18歳に統一するか、あるいは全く別の年齢に統一するかですが、現行の婚姻適齢(16歳または18歳)を積極的に否定する理由が特に存在しないのであれば、他の制度との兼ね合いを考えて、18歳への統一が無難でしょう。
 次に3、現行では6ヶ月となっている女性の再婚禁止期間の短縮ですが、
(再婚禁止期間)
第七百三十三条  女は、前婚の解消又は取消しの日から六箇月を経過した後でなければ、再婚をすることができない。
2  女が前婚の解消又は取消の前から懐胎していた場合には、その出産の日から、前項の規定を適用しない。
 本規定は子どもの権利を保護するものであるため、その兼ね合いで問題が生じてくるのであれば、安易に賛成はできません。しかしながら、こちらも改正を求める声が高まっている民法772条を見てみると、
(嫡出の推定)
第七百七十二条  妻が婚姻中に懐胎した子は、夫の子と推定する。
2  婚姻の成立の日から二百日を経過した後又は婚姻の解消若しくは取消しの日から三百日以内に生まれた子は、婚姻中に懐胎したものと推定する。
 婚姻成立から200日以降の出生ならその婚姻相手との子、解消から300日以内の出生では離婚した相手との子であると推定される規定になっており、仮に再婚禁止期間終了後に即座に再婚したとしても、婚姻から200日後は必ず離婚から300日以上後となりますので、この観点からは特に矛盾はありません。仮に772条とは別の制度との兼ね合いで子どもの立場がまずくなるのであれば、私はこの改正に反対する用意がありますが、そうでないなら積極的に反対する理由はありません。
 4の法定相続分については、現状では以下のように定められています。
(法定相続分) 第九百条  同順位の相続人が数人あるときは、その相続分は、次の各号の定めるところによる。
(中略)
四  子、直系尊属又は兄弟姉妹が数人あるときは、各自の相続分は、相等しいものとする。ただし、嫡出でない子の相続分は、嫡出である子の相続分の二分の一とし、父母の一方のみを同じくする兄弟姉妹の相続分は、父母の双方を同じくする兄弟姉妹の相続分の二分の一とする。
 すなわち、非嫡出子は嫡出子の半分しか遺産を受け取れないという規定です。本問題については以前に取り上げている通りですが、法ができた当初は非嫡出子の権利が非常に低かったものとみられ、本規定は非嫡出子を差別しているというより、むしろ一定の法的な権利を与えたものと考えることができます。事実、本規定が最初に合憲とされた最高裁判決(「平成3(ク)143」、1995年7月5日)では「非嫡出子にも一定の法定相続分を認めてその保護を図ったものであると解される」と指摘されています。
 ただ、その後の社会の変化などもあり、少なくとも現代では「非嫡出子の権利を保護するために半分の権利を与えている」のではなく、「非嫡出子は相続において差別されている」とみなす意見が大勢でしょう。現時点において同様の裁判が起こされた場合には、違憲判決が下される可能性も十分に出てきていますので(最近の判決で今井氏が違憲判断を出し、竹内氏が「相続時なら合憲だが現時点では違憲の可能性が高い」と指摘するなど)、改正を迫られるのも時間の問題です。遅かれ早かれ改正の必要が生じるのであれば、ここでの改正は無難な選択でしょう。
 そして本改正案でおそらく最も重要なのが、1の夫婦別姓制度です。私はかねてから本制度を導入すべきと主張してきましたが、自民党政権下ではまるで実現の見通しが立ちませんでした。ところが、まだ改正されると決まったわけではないものの、民主党政権になって一気に実現の可能性が高まっており、政権交代の効果の大きさを実感するばかりです。政権交代といえば大きな変革を期待するような雰囲気がありますが、二大政党制において大変革が発生する余地は少なく、また政権交代のたびに経済や外交が根本から変わってしまうようでは国が成り立ちません。むしろ本改正案のような、地味なれど重要な改正こそが大事なのです。
 夫婦別姓には反対論もありますが、なぜかその大半が「家族の一体感が損なわれる」なる全く意味不明な主張を繰り返すばかりで、何ら建設的な議論ができない状態です。もし本当に家族の一体感が損なわれるというのなら、主張者はまずそれを示す根拠の提示を行わなくてはなりません。それができないのであれば、「家族の一体感」なる言い分は主張者の妄想であると断じられても仕方がありません。特に同制度に反対する政治家は、国民に対してその根拠をはっきり提示しなくてはならないはずです。
 また、仮に夫婦別姓制度が「家族の一体感」に何らかの影響を与えるとしても、主張者はさらにそれが社会にどれほどの影響を与えるのかを説明しなくてはなりません。もし夫婦別姓が家族の一体感に影響を与える場合があるとしても、それを選ぶかどうかは夫婦の裁量にゆだねられているわけですから、それを禁じるのは他人の家庭に干渉する行為に他なりません。他人の家庭に干渉することがやむを得ないほど社会に多大な損失を与えるのであれば、夫婦別姓を認めないのは仕方がありませんが、そうでなければ認めない理由はありません。
 このように書くと、必ず「夫婦別姓を主張する側に証明責任がある」などと責任転嫁を図ろうとする主張者が現れますが、失笑を禁じえません。夫婦別姓の導入は制限を緩和する行為であり、夫婦別姓を規制するのは自由を制限する行為です。日本では拳銃を所持する自由、酒を飲んで運転する自由などは認められていませんが、これらはいずれも社会を危険にさらすなど、自由を認めるべきでない正当な理由があるためです。すなわち、もし自由を制限しなくてはならないのであれば、制限するに足る理由を提示しなければなりません。立証責任が自由を制限しようとする側にあるのは明白にもかかわらず、これを相手側に押し付けようとする行為は、もはや夫婦別姓を論じる以前の問題であると言わざるを得ません。逆に夫婦別姓を義務化するのであれば、夫婦同姓を否定する理由を提示しなくてはなりませんが、現在提案されているのは選択制ですので、この懸念はありません。
 無論、「現行制度を変更するのであれば、変更するに足る理由が必要である」という主張まで否定する気はありません。しかし、夫婦別姓を導入すべき理由としては、名前を変更する必要があるのは社会生活上不便である、各所への改姓手続きに手間がかかって非合理的、周囲の人間にも手間や混乱を強いる可能性がある、夫婦どちらかが負担を受忍しなくてはならないのは不合理、離婚や再婚などのたびに子の姓までがコロコロと変わる事態になりかねない、別姓のために事実婚を選択せざるを得ないケースもあり、法が時代に追いついていないなど、現実的かつ具体的なものが複数提示されており、これらを否定するだけの反論は未だに見たことがありません。「家族の一体感」なる抽象的かつ事実かどうかすら分からない反対理由を壊れたレコードのように叫び続けるだけでは、これらの賛成理由に対抗できないのは明らかです。改正すべき理由を否定できるだけの反論がなく、しかも自由への制限を緩和する方向の改正である以上、改正を行わない理由がありません。
 一方、もし夫婦別姓で「家族の一体感が損なわれる」ことが証明され、しかも社会に対して夫婦別姓のメリットを帳消しにして余りあるほどの多大な損害を与えると証明された場合、あるいは「家族の一体感」とは全く別の説得力のある理由が提示された場合には、私は夫婦別姓に反対する用意があります。しかしながら、そのようなものはただの一度として提示されたためしがありません。少なくとも、別姓制度に反対している保守派の政治家とやらが、そうしたものを提示したという話は聞きません。これではどうあがいても、反対側にくみできるはずがありません。この有様では、「家族の一体感」なる取って付けたような理由を持ち出すより、「自分が気に入らないから反対する」と正直に述べた方が、到底賛成はできないにしても、まだ好感が持てるというものです。
 ただ、今回の改正案で残念なのは、「子どもの姓は統一」とされてしまっている点です。連立相手や党内の保守派に配慮する意味があるらしいのですが、これでは決して十分な改正案とはいえません。子の出生届時のみ結婚して即座に離婚するような事実婚の形がすでに存在し、事実婚の配偶者に結婚と同じだけの権利があるとみなす判決などにより、司法が事実婚を追認しているのが現状である以上、これらを制度上からも認める改正案こそが求められているはずで、不十分な改正では効果も不十分なものとなってしまう可能性があります。しかし、このまま連立他党の同意が得られず廃案にするよりは、ひとまず夫婦別姓を確実に成立させ、後から改正案を検討しようとする意図であるなら、やむを得ない妥協ではあります。
 子どもの別姓に関しては、ことさら反対派が「家族の一体感」を持ち出そうとする部分ではありますし、確かに過渡期にはそのような問題が発生する可能性は否定できません。しかし、社会が「別姓で当たり前」の世の中となれば、そのような懸念はほとんど払拭されるはずです。なぜ兄弟別姓が奇異に見えるかといえば、現在の社会が同姓を前提としているためです。
 かつて中国には「避諱」の文化がありました。これは高い地位にある人、例えば皇帝の名前を使ってはいけないというもので、皇帝の名前が含まれた地名や官職名が変更されたり、文章ではわざと漢字を避けたり崩したりして書かれるほどの徹底振りでした。一方、日本には貴人の名前の一部または全部を拝借する文化があり、ある有名人が活躍したり話題になった時期には、命名にその名前や漢字が多く使われる傾向にあるようです。このような価値観の文化においては、「避諱」の習慣は理解しがたいものに映ります。また、欧米には親や親族の名前を子に命名する文化がありますが、もし日本でこのようなことをすれば紛らわしいことこの上なく、制度上認められない場合さえあります。しかし現実に、欧米ではこれが普通に行われているのです。
 すなわち、子どもが別姓に違和感を感じるとすれば、それは社会が同姓前提であるために他ならず、別姓が当然の社会では違和感など感じる余地もないのです。無論、過渡期の間だけなら子どもたちが違和感を感じる可能性は残されていますが、それを理由に改正を否定するのであれば、一時的な混乱が生じる可能性のある改正はすべて否定されてしまいます。
 細部をどうするかはともかく、夫婦別姓には現実的なメリットが多く存在する上、少なくとも現状では否定すべき理由が無根拠の主張を除いて一切示されておらず、しかも合理的根拠のない自由への制限を取り去るものである以上、どう見ても当然導入すべき制度です。民主党政権には一刻も早い導入を期待します。

 JPA 2.0でようやく導入された悲観的ロックですが、これに言及したサイトをいくら回ってみても、「悲観的ロックは遅い」の大合唱です。確かに悲観的ロックは時として遅くなる方法ですが、それも状況次第であって、必ずしも遅くなるとは決まっていないはずです。それとも、JPAの悲観的ロックはそれほどひどいのでしょうか。
 ここに数十人の人間がいるとして、これらの人々が1人ずつしか通れない入り口があるとします。人々が我先にと入り口に殺到するものの、それでも1人しか通ることができず、全員が入りきるまで殺到を繰り返すより、全員が整列して順番を待つ方が早いと考えるのは当然な気がしますが、これだけ各サイトで遅いと強調されているからには、JPAでは何かのメカニズムによって楽観的ロックが早い、あるいは悲観的ロックが遅いのかもしれません。もしそうであるなら、悲観的ロックは極限まで避けなくてはならない可能性も出てきます。
 重要な問題ですので、実際に書いて調べてみました。ただ、いつもながら大変いい加減なコードですので、本質的でない点でオーバーヘッドが生じている可能性が否定できません。したがって、決して結果を鵜呑みにしてはいけません。
/WEB-INF
 /classes
  /com
   /yamicha
    /lockcomp
     LockCompareAccess.java
     LockCompareServlet.java
     SampleTable.java
  /META-INF
   persistence.xml
 まずpersistence.xmlはおおむねいつも通りですが、ロギングレベルがFINEでは無駄にログを吐き出してしまい、それでリソースを食われて結果が変化しては困りますので、SEVEREにしてみました。OptimisticLockExceptionはWARNINGですので、これでログは抑制されます。関係ありませんが、severeを辞書で引いてみたところ、「1. extremely bad or serious」「2. causing somebody to suffer, be upset or have difficulties」とありました。ログとしては前者の意味としても、GlassFishとEclipseLinkの数々の不可解な動作によって散々SEVEREを投げられた私にとっては、明らかに後の意味を含んでいます
<?xml version="1.0" encoding="UTF-8"?>

<persistence version="1.0"
  xmlns="http://java.sun.com/xml/ns/persistence">
  <persistence-unit name="MySQL" transaction-type="JTA">
    <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
    <jta-data-source>jdbc/MySQL</jta-data-source>
    <properties>
      <property name="eclipselink.jdbc.driver"
        value="com.mysql.jdbc.Driver" />
      <property name="eclipselink.ddl-generation"
        value="create-tables" />
      <property name="eclipselink.ddl-generation.output-mode"
        value="database" />
      <property name="eclipselink.target-database" value="MySQL" />
      <property name="eclipselink.logging.level" value="SEVERE"/>
    </properties>
  </persistence-unit>
</persistence>
 Javaコードは以下の通りです。トランザクションをコンテナに任せると都合が悪いため、今回はUserTransactionを使用しました。OptimisticLockExceptionが投げられた場合はロールバックして作業をやり直しています。
 なにぶんいい加減なコードですので、不可解なオーバーヘッドが含まれているかもしれません。
// SampleTable.java
package com.yamicha.lockcomp;

import javax.persistence.*;

// カウンタとバージョンを持つだけの単純な Entity
@Entity @Table(name="lockcomp_table") public class SampleTable
	implements java.io.Serializable{
	private int id;
	private int counter;
	private int version;

	public SampleTable(){
		counter = 0;
	}
	public SampleTable(int i , int c){
		id = i;
		counter = c;
	}

	@Id @Column(name="id") public int getId(){
		return id;
	}
	@Column(name="counter") public int getCounter(){
		return counter;
	}
	@Version @Column(name="version") public int getVersion(){
		return version;
	}

	public void setId(int i){
		id = i;
	}
	public void setCounter(int i){
		counter = i;
	}
	public void setVersion(int i){
		version = i;
	}
}

// LockCompareAccess.java
package com.yamicha.lockcomp;

import javax.ejb.*;
import javax.annotation.*;
import javax.persistence.*;
import java.util.List;
import java.util.ArrayList;
import javax.transaction.*;

// トランザクションを自分で制御する必要があるので BEAN を設定
@TransactionManagement(TransactionManagementType.BEAN)
  @Remote
  @Stateless(name="LockCompareAccess" , mappedName="ejb/LockCompareAccess")
  public class LockCompareAccess{
  @PersistenceContext(unitName="MySQL") private EntityManager em;
  // UserTransaction は @Resource をつけるだけで取得できる
  @Resource private UserTransaction ut;

  // 前処理
  public void regist(){
    try{
      ut.begin();
      em.persist(new SampleTable(1 , 0));
      ut.commit();
    }catch(Exception e){
      throw new RuntimeException(e.toString());
    }
  }
  // カウンタのインクリメント
  private void addCount(LockModeType mode) throws Exception{
    ut.begin();

    SampleTable sample = em.find(SampleTable.class , 1 , mode);
    sample.setCounter(sample.getCounter() + 1);
    em.merge(sample);
    em.flush();

    ut.commit();
  }
  // 成功するまで更新処理を繰り返すメソッド
  public void add(LockModeType mode){
    while(true){
      try{
        addCount(mode);
        break;
      }catch(OptimisticLockException e){
        try{
          ut.rollback();
        }catch(Exception re){
          throw new RuntimeException(e.toString());
        }
      }catch(Exception e){
        // 念のため、OptimisticLockException 以外を投げた場合の処理
        // RuntimeException を送出して処理を終わらせる
        try{
          ut.rollback();
        }catch(Exception re){
          throw new RuntimeException(e.toString());
        }
        throw new RuntimeException(e.toString());
      }
    }
  }
  // カウンタ値の取得
  public int getCounter(){
    return em.find(SampleTable.class , 1).getCounter();
  }
  // 後処理
  public void remove(){
    try{
      ut.begin();
      em.remove(em.find(SampleTable.class , 1));
      ut.commit();
    }catch(Exception e){
      throw new RuntimeException(e.toString());
    }
  }
}

// LockCompareServlet.java
package com.yamicha.lockcomp;

import javax.servlet.annotation.*;
import javax.ejb.*;
import javax.annotation.*;
import javax.servlet.*;
import javax.servlet.http.*;
import javax.persistence.*;
import java.io.*;
import java.util.List;
import java.util.ArrayList;
import java.util.Date;

@WebServlet(name="lockcompareservlet" , urlPatterns={"/*"})
  public class LockCompareServlet extends HttpServlet{
  @EJB(beanName="LockCompareAccess") private LockCompareAccess ca;

  // 使用するスレッドの数
  // あまり多すぎるとリソースを消費する他、データベースの
  // 接続プールが足りなくなってエラーを出したりするため、
  // 環境に合わせた値に設定する
  // 十分な処理能力とデータベース接続能力がある場合、
  // この値ではおそらく小さすぎる
  private static final int THREAD_COUNT = 10;

  // カウンタを更新するスレッド
  class LockThread extends Thread{
    private LockModeType mode;

    public LockThread(LockModeType m){
      mode = m;
    }
    public void run(){
      ca.add(mode);
    }
  }

  private List<Thread> createThreads(LockModeType mode , int count){
    List<Thread> threads = new ArrayList<Thread>(count);
    for(int i = 0; i < count; i++)
      threads.add(new LockThread(mode));
    return threads;
  }
  private void startAll(List<Thread> threads){
    for(Thread t : threads)
      t.start();
  }
  private void joinAll(List<Thread> threads){
    for(Thread t : threads){
      while(t.isAlive()){
        try{
          t.join();
        }catch(InterruptedException e){
        }
      }
    }
  }

  public void doGet(HttpServletRequest request ,
    HttpServletResponse response) throws IOException{
    response.setCharacterEncoding("UTF-8");
    response.setHeader("Content-type" , "text/plain;charset=UTF-8");
    PrintWriter out = response.getWriter();

    ca.regist();

    out.println("楽観的ロックの時間を計測しています。");
    List<Thread> optimistics = createThreads(
      LockModeType.OPTIMISTIC , THREAD_COUNT);
    long opt_time = new Date().getTime();
    startAll(optimistics);
    joinAll(optimistics);
    opt_time = new Date().getTime() - opt_time;

    // 正しくカウンタが更新されているかを確認するために
    // カウンタの値を表示する
    out.println("カウント: " + ca.getCounter());

    out.println("悲観的ロックの時間を計測しています。");
    List<Thread> pessimistics = createThreads(
      LockModeType.PESSIMISTIC_WRITE , THREAD_COUNT);
    long pes_time = new Date().getTime();
    startAll(pessimistics);
    joinAll(pessimistics);
    pes_time = new Date().getTime() - pes_time;

    out.println("カウント: " + ca.getCounter());

    ca.remove();

    out.println("楽観的ロック: " + opt_time);
    out.println("悲観的ロック: " + pes_time);

    out.close();
  }
}
 これを実際に動かしてみたところ、楽観的ロックの場合はどうしても1300〜1400ms必要なところを、悲観的ロックなら400ms以下で終わらせてしまいます。楽観的ロックの場合、最悪のケースを想定すると、10個のスレッドがいっせいに処理を行ってコミットしようとして9スレッドが失敗し、その9スレッドがまた処理をしてコミットしようとして8スレッドが失敗、といった具合に9+8+7+...+2+1回も失敗する恐れがあり、遅くなるのは当然です。
 このケースはあくまで極端な例であって、楽観的ロックの方が軽い局面も多いとはいえ、JPA 2.0でも悲観的ロックが特にひどいわけではないようです。状況次第では、むしろパフォーマンスの改善のために悲観的ロックを取り入れる選択肢さえあります。何にしても、JPA 2.0に悲観的ロックが導入された点と、JPA 2.0の仕様をろくすっぽ実装していない中では珍しくGlassFish v3 Preview + EclipseLinkが悲観的ロックをサポートしている点はありがたいです。
 JPA 2.0の新機能としては、悲観的ロック以外にもUnidirectional OneToManyを試してテーブルが生成されずに撃沈したり、@MapKeyColumnの対応が中途半端でそのままでは動作せず、ログのクエリから方法を推理して強引に動作させてみたりしていますが、これらについては次の機会としておきます。
カテゴリ [開発魔法][社会問題] [トラックバック 0][コメント 0]
<- 前の記事を参照 次の記事を参照 ->

- Blog by yamicha.com -