is the free-software Prevalence layer for Java.
最早关注到prevayler是一年å?Šå‰?的事了。当时在网上éš?便乱转的时候,çª?然å?‘现有个å?«prevayler的东东获得了jolt 14届的大奖。好奇之余便跑到了主页上去看个究竟。乖乖,一看å?¯是å?“了一跳,人家å?·称比oracle快9000å€?,比mysql还快3000å€?ï¼?牛皮å?¹破天了å?§?细细看æ?¥,原æ?¥人家独辟蹊径,把数æ?®全部放在内存里,而且是以对象的形å¼?。在内存里速度当然应该更快,而以对象的方å¼?则使用起æ?¥更自然。
将数æ?®全部ä¿?存在内存里,å?¬起æ?¥有点ä¸?å?¯æ€?议,prevayler的价值观很简å?•,现在内存的价格越æ?¥越便宜,增加内存的代价原比增加oracle的licenseè¦?便宜许多。在prevayler独特的高å?¯é? 性和高扩展性ä¿?è¯?下,原æ?¥越å?¸引我的眼ç?ƒï¼?当年最疯狂的技术å?£å?·便是:你还在使用数æ?®库å?—?ï¼?
公å?¸希望能够有快速原形的开å?‘能力,prevayler便å†?一次进入我的候选å??å?•。é‡?新下载prevayer的æº?代ç ?,此时的版本已ç»?是2.0.006了,让它自带的例å?跑起æ?¥还是比较的容易,我就ä¸?在此唠å?¨。ä¸?过,ç»?过几个例å?的å°?试,我å?‘现了一些容易让大家误解的概念ï¼?
首先:prevayler在通过æ¯?个Transaction把对象æŒ?久化的时候都是采用深度拷è´?的方å¼?,也就说å?³使是多对一的关系,例如book -> author这样的关系,æ¯?个book中都会ä¿?存author完整的信æ?¯,而ä¸?是引用ï¼?如果我们应用一下æ“?作getBookById(3).getAuthor().setAge(36)的到的结果居然是:
book[id:0, title:book1, author[id:0,name:foo,age:35]];
book[id:1, title:book1, author[id:0,name:foo,age:35]];
book[id:2, title:book1, author[id:0,name:foo,age:35]];
book[id:3, title:book1, author[id:0,name:foo,age:36]];
这个让我刚开始的时候ç?€实疑惑了一会。这样的结果就是我们ä¸?能在对象中ä¿?留å?¦一个对象的引用,而å?ª能ä¿?留å?¦一个对象的id之类的引用。然å?Ž通过查询这个id获得需è¦?的对象。å?¦则,整个系统的行为ç»?对出乎你的æ„?料ï¼?
其次,所有对æŒ?久化对象的æ“?作必须是在Transaction内完æˆ?,å?¦则无效。这个和hibernate的概念比较接近。
prevayler系统并ä¸?是一个OODB,所以大家没有必è¦?设计一个object的cantainer,然å?Ž把所有的数æ?®都æŒ?久化在这个cantainer内。
Prevayler确实是一个大胆而å?ˆ有创造性的开æº?项目,虽然还ä¸?能说是尽善尽美,但是确实为我们æ??供了å?¦一个æŒ?久化的选择。æ?®说google所有的数æ?®都在内存中查询,那我们利用Prevayler和它的cluster机制å?Žå?ˆ能å?š些什么呢?