02.27.06

AJAX frameworks comparison

Posted in Web Development at 1:04 am by skoobi

Daniel provides a comparison of AJAX frameworks . It is especially useful these days since everyone is starting to develop his own AJAX framework.

Not all frameworks are presented (reasons explained), but it’s a good start. Keep up the good work !

Permalink Comments

02.15.06

Aspect-Oriented Programming

Posted in Methodologies at 12:47 pm by skoobi

This very nice article from IBM gives some information about Aspect-Oriented Programming (AOP), and why it is good for programmers.

The author clears the myths and understanding about AOP.

Permalink Comments

02.12.06

Basic Db4o Integration with Spring.NET

Posted in .NET at 9:59 am by skoobi

Basic Integration of Db4o with Spring.NET is now done. Nothing has been tested yet, but testing should soon start…

I have created a JIRA issue for this. I hope that this will get integrated and reviewed into Spring.NET.

Content of the issue :

It would be nice to have Spring.NET integrated with db4o.
I have implemented basic integration here :
http://samokk.is-a-geek.com/Projects/Spring.Net/db4o.tar.gz

Nothing has been tested yet.
I’ll post updates to the same address.

The current version supports :
- Db4o Platform Transaction Manager :
- Db4o Template, that supports both ICallback and delegate method.
- Db4oUtils, that provides utilities to create / dispose connections
- IDb4oDataSource / BasicDb4oDataSource : the exact same thing as a Java JDBC DataSource (Abstract Factory), but for Db4o. BasicDb4oDataSource delegate connection creation to 4 concrete IDb4oConnectionParameters :
* FileDb4oConnectionParameters : Direct file access
* MemoryDb4oConnectionParameters : In-memory database
* EmbeddedClientDb4oConnectionParameters : client to an embedded server
* RemoteClientDb4oConnectionParameters : client to a remote server

These classes work with the Spring.Data classes I found in the sandbox. Do not hesitate to add them to CVS, they are licensed under whatever-license suits you (Apache, BSD, LGPL, whatever)

Permalink Comments

02.10.06

More details about Integrating Db4o with Spring.NET

Posted in .NET at 5:53 pm by skoobi

After having spent several more hours on the Db4o/Spring.NET integration issue, here are some of my conclusions concerning Spring.NET internals :

Most of the logic for integrating a Data Access/Transaction support technology to Spring.NET is to be implemented inside 3 major entities :

The PlatformTransactionManager (Db4oPlatformTransationManager) : definitely the main entity on the system, its purpose is to manage the transactions (Commit, Rollback, and Get a (New/Existing) Transaction.
The Utilities (Db4oUtils) : Its role is mainly to create / dispose connections. However, it does NOT blindly create connections and dispose them. In fact, it must take into account the fact that most applications are multithreaded (e.g. Web Sites), so the releasing a connection must not affect another thread’s connection.
The Template (Db4oTemplate) : Its role is simply to remove the connection creation/release burden from user code. The template takes care of dealing with Spring.NET internals, threads, synchronization, etc. As a result, the user code just deals with a connection to the database that it can use to perform its tasks.

Let’s see how everything fits together :

First of all, it is important to realize that connection creation is an important part of the whole system. In fact, in a multi-threaded environment, several concurrent accesses to the database will be necessary. As a result, it is not possible to have code (e.g. Data Access Objects - DAO) keep references to active connections since it woud mess the whole system. To concurrently access the same database at the same time, several threads must use different connections, so data access code should not maintain references to connections.
As a result, most parts of Spring.NET (Template, etc) will keep a reference to a Factory Object that allows the creation of connections, instead of keeping a reference to a connection directly. This Factory is the DataSource, in the case of Spring Java and IDb4oDataSource in the case of my Db4o to Spring.NET integration.
The Spring.NET templates (Db4oTemplate) allow the removal of connection references from Data Access Objects. Indeed, when using templates, DAOs provide delegates (implemented as Object callbacks for Spring Java, since delegates (function pointers) do not exist in Java) whose signature is given by the template. The delegate has the connection object passed as a parameter, so the DAO can actually perform its work without having to care about which connection it will work on. Look at Spring (Java) reference manual which gives quite a lot of information about this.
As a result, all the connection creation/release tasks are handled by the template instead of the user. This is coded once in the template, and avoids unecessary boilerplate code. Basicaly, here is how (roughly) a template Execute method is coded :

Get a Connection
Call the delegate provided by the user : delegateMethod(Connection)
Close the Connection

However, Connection Creation and Release is a quite complex task. As a result, it is handled by a utilitary class : Db4oUtils. Here is why it is complex :

Connections used by each Thread should be handled separately. Thread X should not mess with Thread Y’s connection, or it would lead to race conditions.
It is not possible nor desirable to create a new connection each time a connection is requested. In fact, the connection should be kept until the transaction is Commit’ed or Rollback’ed, and several calls to GetConnection() can happen before, if, for example, several Db4oTemplates are used.
Sometimes, we do not want to take part in a Transaction, so the case where there is no transaction to synchronize to should also be taken into consideration.
Additionnally, Exceptions should be converted to Spring.NET exception Hierarchy..

In order to handle each thread’s connection separately, a TransactionSynchronizationManager is used. Its role is simply to associate resources and give different resource-spaces to each thread.
The resources that the TransactionSynchronizationManager deals with are not the connections direcltly, but ConnectionHolders. The subtle difference is that the holder maintains a reference to the Connection, but also keeps some information such as a reference count of users of the connection. So, in the case of nested GetConnection() calls, the reference count will indicate that the resource is still used even though a Dispose() will be done after the nested GetConnection().
The TransactionSynchronizationManager uses an event-based approach with listeners (called Synchronizations to the resources) in order to do the cleanup of the resources; Since the TransactionSynchronizationManager works with all kinds of connections (ADO.NET, Db4o, etc), it cannot understand how it should cleanup resources after a cleanup, so this is the task of a Synchronization that listen to events thrown by the Manager.

Previous issues :

Permalink Comments

02.09.06

Spring.NET and db4o Integration roadmap

Posted in .NET at 3:12 pm by skoobi

As previously stated, I am currently working on Spring.NET and db4o Integration.

This thread deals with some of my questions regarding what’s currently available in db4o that will allow me to do the job.

Here’s the likely roadmap :

Create an equivalent of the JDBC “Datasource” : a Factory that allows to create connections regardless of their type (embedded, remote, etc). This will help to abstract the connection creation and provide different implementations (Basic, Pooled) of this creation.
Create a Basic non-pooled implementation of this Db4oSource
Implement a Db4oTemplate, probably based on Db4o Native queries (S.O.D.A not doable, unless something is changed on Db4o side)
Implement the Db4oPlatformTransactionManager and its supporting Db4oUtils classes
Some day, in the future, provide a Pooled implementation of the Datasource. Inspiration from Commons-DBCP will be necessary :

A proxy should be created for Db4o ObjectContainer, that would mostly just delegate the processing to a real ObjectContainer, except for the Close(), which would tell the pool that the connection is available

Permalink Comments

02.08.06

Is Architecturing the task of ONE person, not a community ?

Posted in Internet at 8:33 am by skoobi

T his email from Novell is particularly interesting to read.

I believe that they got it right : if you want things to go forward, you sometimes have to create something even though some people won’t like it sometimes.

It is especially true for Novell, since they are trying to push the .NET framework and as soon as we talk about high level languages, all the C/ASM-lovers stand against it.

Permalink Comments

02.07.06

Adding db4o OO database support for Spring.NET Transactions

Posted in .NET, Tips and Documentation at 3:19 pm by skoobi

Compared to its Java peer, Spring.NET’s transaction support is still in its infancy and somewhat undocumented.
According to some posts in the forum, Transaction support should come with version 1.1 (currently in CVS).

In the meantime, those of us who have to deal with transactions still have to find a solution.. The first step is to get a nightly snapshot build of the CVS and copy the Spring.Data classes from the sandbox.

The second step is to understand how Transactions are supported and the last step is to add support for your Data backend if it is not yet supported (only ADO.NET is supported, as far as I know.. Maybe iBatis.Net is too, at least partially).
So, concerning the second step, this thread should help to understand once people give some answers…

This post is to give more details of what I understand in the hope that it will help someone else in the same position :

First of all, It is necessary to understand the real problem, so here is a scenario :

A Database maintains all data for a website
A website has several visitors working concurrently (Several threads will be concurrently accessing the database at the same time, each one serving a visitor)
It is NOT acceptable (for performance reasons) to open a new connection every time something must be SELECT’ed or UPDATE’d, then closed.
Database sessions can either be commit’ed (successful registration on the website) or rollback’ed (client gone before the end of the registration).

Then, it is important to read about Spring (Java) Transaction support, since Spring.NET is highly inspired about its Java counterpart. It’s basically the only documentation we have, so let’s read it, it’s way easier to understand than API documentation
So, to sum-up Spring Transaction Support: The PlatformTransactionManager (e.g. AdoPlatformTransactionManager for ADO.NET), TransactionSynchronizationManager and Template (AdoTemplate) classes are particularly important.

All Data access code should be run by PlatformTemplate.Execute (AdoTemplate) that will take care of all the resources initializasation/cleanup, as well as transaction synchronization if necessary (the Template still works if there is no transaction to synchronize to).
TransactionSynchronizationManager takes care of managing resources and transaction synchronizations per thread. In fact, the problem to solve is about assigning a Transaction and its corresponding connection to every thread that wants to access the database. Depending on the underlying infrastructure and configuration, we may reuse already existing connections -instead of creating and closing systematically - (connection pool such as Commons-DBCP in the Java World) and synchronize them to a transaction. However, this class does not deal with anything else than just keeping the resources of each thread. All the connection/transaction to thread assignment logic is done by the PlatformTransactionManager
PlatformTransactionManager (AdoPlatformTransactionManager) : this component returns a currently active transaction or creates a new one based on the given parameters (Isolation level, etc).

TransactionTemplate complements AdoTemplate. While AdoTemplate is used to make sure data access code will be synchronized to a currently used transaction, TransactionTemplate is used to demarcate transactions. In other words, it can be used in non-data access code (higher-level services that use DAOs directly or indirectly), to tell where a transaction begins and where it ends.

The use of TransactionTemplate is not mandatory, but not using it will imply that calling AdoPlatformTransactionManager methods will be up to the user…

Declarative TransactionDemarcation can also be used (and is recommended), but for the sake of clarity, we won’t add another layer of complexity here. Spring.NET’s AOP-style declarative transaction demarcation can be seen as the dynamic creation of a proxy around a service class that will just wrap the method calls inside the previously described TransactionTemplate. Then, other beans must use the generated proxy instead of the actual class. But as you can see, the underlying principle concerning Transaction stays the same : we rely on a TransactionTemplate.

So, overall, things do not seem that complex.. Let’s analyze a bit more.

PlatformTransactionManager is the main actor on the scene. Its role is to Create/Reuse transactions, commit and rollback transactions. It conforms to the IPlatformTransactionManager interface that defines the following methods :

ITransactionStatus GetTransaction( ITransactionDefinition definition );
void Commit( ITransactionStatus transactionStatus );
void Rollback( ITransactionStatus transactionStatus );

ITransactionDefinition defines all the gory details of the transaction (Propagation behavior, Isolation Level, Timeout, etc). See Wikipedia for more information about these general Database concepts.

So basically, when we want to perform a transacted set of tasks, the code should look like (taken from Spring Java documentation) :

DefaultTransactionDefinition def = new DefaultTransactionDefinition();
def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);

TransactionStatus status = txManager.getTransaction(def);
try {
// execute your business logic here
}
catch (MyException ex) {
txManager.rollback(status);
throw ex;
}

txManager.commit(status);

In other words, this is the manual way of demarcating transactions (e.g. the “wrong” way). But at least, things are pretty clear about what’s done on the system. (txManager is the platform transaction manager, AdoPlatformTransactionManager, for example).

The good news is that it is exactly how TransactionTemplate wraps service code, in the Execute() method :

public object Execute(ITransactionCallback callback)
{
ITransactionStatus status = _platformTransactionManager.GetTransaction( this );
object result = null;
try
{
result = callback.DoInTransaction( status );
}
catch ( Exception ex )
{
rollbackOnException( status, ex );
throw ex;
}
_platformTransactionManager.Commit( status );
return result;
}

As you can see from the code no magic is done here, we purely rely on the PlatformTransactionManager to perform some logic that will make sure the connections and transactions don’t get mixed and matched between threads…

So, let’s see how PlatformTransactionManager works.. Of course, you can already envision that a lot of things are going to be pretty much the same no matter what the concrete platformTransactionmanager is. In fact, no matter whether you use ADO.Net, iBatis.Net, or whatever else, the following workflow handling is hardcoded into AbstractPlatformTransactionSupport, from which all concrete PlatformTransactionsupport should inherit :

Determines if there is an existing transaction
Applies the appropriate propagation behavior
Suspends and resumes transactions if necessary
Checks the rollback-only flag on commit
Applies the appropriate modification on rollback (actual rollback or setting rollback-only)
Triggers registered synchronization callbacks (if transaction synchronization is active)

The basic idea here is that the three methods (GetTransaction(), Commit() and Rollback() are implemented and use the Strategy Design Pattern to delegate actual processing to the concrete subclasses (All the Do*() methods).
So, all the dirty work of complying with the API is already done, and the real work left is about coding the parts that are different with each system, such as beginning a transaction (DoBegin()).

The link with TransactionSynchronizationManager is done, for example in DoBegin by :

TransactionSynchronizationManager.BindResource(DbProvider,
txMgrStateObject.ConnectionHolder);

The ConnectionHolder (which represents the Connection + Transaction) is bound to the thread by the static BindResource which will use a [ThreadStatic] Collection to take care of the Threading stuff. (See more information about the TreadStatic Attribute on MSDN).

However, one thing that I am still unsure about is how connection ressources are disposed. After committing, we do not want to close the session, we just want to tell the PlatformTransactionManager that the resource is now free to reuse for some other thread.

To put it in a nutshell, in order to add support for a new transaction system, here are the required elements :

a Template class
A transaction Manager
Utils class (used by the template and Manager to create/open/close connections)

This should be enough to get a working implementation. I’ll create one for db4o OO database.

Permalink 4 Comments

Linux : Finally on the desktop thanks to OpenGL ?

Posted in Unix / Linux at 9:23 am by skoobi

Thanks to Novell !! See this announcement from Miguel de Icaza or this one from Alexandre Gomes for Xgl and the new compositing manager ..

I am looking forward to having everything working on my Ubuntu box… And having applications (f-spot, etc…) using this technology intensively.

So now, what does the Graphical Layering look like, under Linux ? How is Cairo/Glitz related to Xgl ? As far as I understand :

Cairo is the equivalent of Apple Quartz: it provides a vector-based graphics library. In other words: an API that allows you to draw lines, rectangles, etc. Cairo then uses one of its backends (such as Glitz) to do the actual rendering
Glitz is an image compositing library based on OpenGL. It can be used directly, but also integrates with Cairo. An example of OpenGL rendering with Glitz can be found here.
GTK+ is a widget toolkit that uses Cairo for the drawing of its components. In other words : GTK+ provides windows, buttons, text areas, etc, and Cairo is used to draw the lines to represent these buttons.
Xgl is the future of X.org Server, layered on top of OpenGL and Glitz.

So, as far as I understand, things would be rendered this way :