Thursday, August 12, 2010

Yesterday Mike Tallent, via Twitter, made his congratulations to me for my recent "Db4o community award".

Is it a joke? The reason seems to reside in the homepage of TevereFlow that claims to support db4o. After some private messages with a db4o guy I explained that TevereFlow supports db4o since it uses DataNucleus as OR-Mapping and it supports db4o. Therefore TevereFlow can run on top of db4o but the support is indirect. All clear.

But after some days I found my name in the "DB4O MOST VALUES PROFESSIONAL" list:



Thanks a lot, but I never have written a single line of code for/with db4o!

Furthermore I'm the author of OrientDB, a competitor of db4o.

So is it a joke? :-)

Friday, February 19, 2010

Romulus workshop in Madrid

Madrid, February 18th 2010. The day seems to be finished and it has been a pretty long day for me. This morning wake up at 7:30 o'clock, 8:30 breakfast at the Starbucks in front at the hotel and then straightforward to the Universidad Politécnica de Madrid (UPM) for the Romulus meeting and for the Romulus Workshop in the afternoon.

Today I've presented Roma Meta Framework to a bunch of students and some business IT men interested on the fast developing of Web Applications following the DDD approach, the Meta Framework philosophy and obviously Roma. We have had a hands-on session where almost all the attendees tried to follow me step by step on the building of a simple social application. I hope today the Roma community welcomes some new committers.

Below some photos shooted by Marco.



Anyone is in Madrid until Saturday morning?

Saturday, February 13, 2010

Orient DB almost ready for the show time!

After some weekends of work I've in my hands the first version of Orient DB! I wrote a lot of Unit Tests that helped me a lot on the heavy refactoring in order to achieve the best performance than ever. The main features of Orient are:
  • Full ACID: Optimistic transaction available with recovery of aborted transactions when the engine restarts. Tested with 1 billion of records even with simulated crashes during the commit phase. Pessimistic (with object-level locking) transaction in the next releases.
  • Extremely light: less than 400kb of jar without any dependency with other libraries
  • Super fast: stores 1,000,000 (yes one million) of records in 3.5 seconds on common hardware (my notebook). The KeyValue engine stores 100,000 entries indexed in 9 seconds. Lookups are so fast as memory access.
  • tested up to 1 billion of records, but the limits are up to 9.223.372.036 Billions. Actually I think I'll never will be able to include this test in my Unit tests :-)
  • A lot of cool features such as Asynchronous Queries, SQL language, Partitioning of data, native sharding support, and more
  • Requires: Java5 or major and run on all the most used Operative Systems.
What about the license? I have no choose yet, maybe LGPL?

http://www.orientechnologies.com.

Thursday, December 24, 2009

Released TevereFlow, the first workflow engine with a Web Editor

Starting from December 22nd 2009 is available the new version of TevereFlow.

Tevere Flow is a light-weight Workflow engine built using the Java® technology. Just download it and create your process using the Web interface. You can use Tevere as embedded or as external engine by using the provided Web Services API.

Tevere was built using Roma Framework under the Romulus consortium an it's currently used in several production systems.

Main features:

  • Open Source Apache 2.0 license
  • Web User Interface using the Ajax technology
  • Stand-alone application: just download and start it
  • Fully Transactional supporting any RDBMS or db4o ODBMS
  • Set of built-in commands available (email, web service invocation, etc.)
  • Auto-resume of failure activities
  • User and profile management
  • Activities can be written in Java or using any supported scripting language such as Javascript and Ruby
  • Integration via Java APIs or WebService

Tuesday, December 22, 2009

Search on Freshmeat

After I've posted the last release 2.1.0 of Roma Meta Framework on Source Forge I tried to search the project by typing "Roma" in the search field of Freshmeat home page:

0 search results for: roma

What???? If I type "Roma Framework": the result is always 0 (zero) results but with the result table filled:

Maybe they require an exact search? Not properly, since if I try to search for "framework":

1941 search results for: framework

What kind of search is it?

Thursday, October 01, 2009

Terracotta as distributed DBMS? Bad idea!

Some months ago I have had a fucking genius idea about a new application. In order to start working to my idea I need to distributed at large tons of objects in several nodes around the Internet. After a deep research about all the best solutions available now I decided to try Terracotta.

Basically I need a real distributed Object repository so why don't create a simple Object DBMS virtually all in RAM and let to Terracotta most of the hard work?
  1. Handle the cache on nodes
  2. Manage the object/page fault in a transparent way for the application
  3. Share the load among nodes
  4. And obviously: read/write objects in persistent way
So I've developed a very simple library that uses the JDK 1.6+ TreeMap to collect data and to query them. I was surprised to discover how much terracotta makes a good job in hiding the dirty work and complexity of data distribution.

But before to think to use this piece of code in a production system I need to be sure that the objects became really persistent in ACID way. For this reason I developed some Test Cases as microbenchmarks to see the real throughtput and if data are written in synchronous way to the disk. This was my test using the library I wrote:

UserDatabase db = ServerNode.getInstance().connect("petshop", null, null);
clazz = db.getClazz("Animal");

for( int i = 0; i < 100000; ++i ){
UserObjectTransient object = clazz.createObject();


object.setValue("name", "Gaudi");
object.setValue("description", "My crazy ferret!");
object.setValue("from", "Barcelona, Spain");
object.create();
}


Pretty nice, don't you? The Terracotta server instance was on a remote server with 1GB of heap and enought bandwitch available and the client runned on my laptop. Yes I know, this is a microbenchmark and can't tell to me the performance in all the scenarios. But to go on on my experiments I needed to know if I was totally crazy or if there was a way to build a robust & scalable solution to satisfy my needs.

Well, in this test my library + Terracotta (after some tuning by reading the documentation and the forum) are able to write around 190 objects per second. Not really bad for the first release and in comparison to a RDBMS solution. But I've stored just a dynabean with two properties... I remember in the past (about 8 years ago!) when I tried a real ODBMS (Orient ODBMS) it was able to store 100x of this solution using a 8-years-old hardware!

But the really bad news is another one: When the "for cycle 100.000" was finished and the application seemed to be succesfully ended I noted that the console had no control. The test was still running! After 10 seconds I killed the java process and counted the objects created (using the Terracotta console): 99.345!

Where are the 655 objects missed? Ok, probably I got wrong about ACID features. No, the Terracotta documentation tells ACID! But how it can be ACID if the client sends the objects to the server in asynchronous way?

I'm pretty confident that it would be exist in any point of configuration the real synchronous mode but even though it exists what about the performance? If this ASYNCHRONOUS solution was able for 190 obejcts/sec as throughtput the synchronous one must be much more slow!

These are the reasons why I abandoned this path. Terracotta surely fits well in traditional replication contexts and the product is really good on documentation, presentation, APIs, etc. But for my needs I have to continue in searching...

Monday, September 21, 2009

Remove the persistence layer at all to scale up?



In these days I'm working for a brand new idea that need to scale out (close to the infinite?) and after a lot of thoughts about its architecture I'm seriously evaluating to remove the persistence layer using a distributed in-memory cache, obviously with the "fail-over" feature: Terracotta.

Terracorra, under the hood, records all changes happened to the objects using BerkeleyDB. All is transparent to the application and on crash the server swaps to another one configured without interruption and leaving all objects consistent. Or, at least, it seems to be so.

Does anyone have never used Terracotta in a real-world application without a DBMS to store data?

Thursday, September 17, 2009

Roma Framework and the Virtual Objects

Yesterday night I've committed in the Roma's SVN (revision: 4479) source repository the first version of Virtual Objects. Virtual Objects are like POJO, but built dinamically just using a descriptor, in this case a XML file. The XSD is the same of Roma XML annotations but now allows to specify the field type and in future declaring inheritance and other stuff.

Action implementation can be written using any scripting language is supported by JSR 223, Javascript in primis.

Roma treats Virtual Objects in the same way of POJO, so you can define an Employee at the fly in this way:


<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<class xmlns="http://www.romaframework.org/xml/roma" xmlns:xsd="http://www.w3.org/2001/XMLSchema-instance"
xsd:schemaLocation="http://www.romaframework.org/xml/roma http://www.romaframework.org/schema/v2/roma.xsd">
<aspects>
<view>
<form>
<area name="main" type="column">
<area name="fields" size="2" type="grid" />
<area name="actions" type="row" />
</area>
</form>
</view>
</aspects>
<fields>
<field name="id" type="Integer" />
<field name="name" type="String" />
<field name="surname" type="String" />
<field name="born" type="Date" />
<field name="age" type="Integer">
<aspects>
<view enabled="false" />
</aspects>
</field>
<field name="salary" type="Float" />
</fields>
<actions>
<action name="refresh">
<aspects>
<scripting>
org.romaframework.core.Roma.objectChanged(me);
</scripting>
</aspects>
</action>
<action name="print">
<aspects>
<scripting>
print(age);
</scripting>
</aspects>
</action>
<action name="login">
<aspects>
<scripting>
print('Login...');
org.romaframework.frontend.RomaFrontend.flow().forward("ProjectLogin");
</scripting>
</aspects>
</action>
</actions>
<events>
<event name="show">
<aspects>
<scripting>
<![CDATA[
age=32;
Roma.fieldChanged(me, ["age"]);
]]>
</scripting>
</aspects>
</event>
</events>
</class>


And this is the result:
Note that changes to the XML files are loaded in real-time enabling a real productive development (and production why not) environment.