Yesterday I met Jonas Boner, one of Terracotta people. His presentation and demo show to me again the powerful of this tool.
Terracotta allows to cluster any application acting on single POJO by enhancement (byte code changing).
I've planned to integrate in Roma Framework for the next week!
Friday, March 30, 2007
Sunday, March 25, 2007
Working on Roma's PersistenceAspect
After the last application developed using Roma Meta Framework I spent much time to refactor and optimize the performance of PersistenceAspect module. Until now Roma always used the JDO detaching mode. It works very well for the most cases, but when you had to execute many operations inside the same transaction or when you don't need to have the objects writeable.
JDO Detaching consumes a lot of CPU resources since the objects are copied and memory since for the same reason. For normal CRUD operation the difference is trascurable, but in long transactions is very sensible.
For this reason I've refactored the PersistenceAspect to have 3 implementations:
- AtomicPersistenceAspect: operations are always atomic and it continue to uses the "classic" detach mode.
- TxPersistenceAspect: operations share the same transaction (you had to call commit/rollback methods!) and you can access to the objects also after the commit/rollback in read-only mode
- NoTxPersistenceAspect: No transaction is used and you can access to the objects also after the commit/rollback in read-only mode
Furthermore you can select the strategy also when you retrieve the object by:
- PersistenceAspect.loadObject()
- Query.setStrategy()
In the next week I'll migrate all CRUD operations to use the NoTx Strategy.
I started also to write a detailed HowTo about the Persistence Strategy.
Stay tuned!
JDO Detaching consumes a lot of CPU resources since the objects are copied and memory since for the same reason. For normal CRUD operation the difference is trascurable, but in long transactions is very sensible.
For this reason I've refactored the PersistenceAspect to have 3 implementations:
- AtomicPersistenceAspect: operations are always atomic and it continue to uses the "classic" detach mode.
- TxPersistenceAspect: operations share the same transaction (you had to call commit/rollback methods!) and you can access to the objects also after the commit/rollback in read-only mode
- NoTxPersistenceAspect: No transaction is used and you can access to the objects also after the commit/rollback in read-only mode
Furthermore you can select the strategy also when you retrieve the object by:
- PersistenceAspect.loadObject()
- Query.setStrategy()
In the next week I'll migrate all CRUD operations to use the NoTx Strategy.
I started also to write a detailed HowTo about the Persistence Strategy.
Stay tuned!
New logo for Roma [Meta] Framework
Luca Bianconi is the author of the new Logo of Roma [Meta] Framework. It's online starting from friday 23 March 2007.
The logo is very simple and was inspired by Roma city (Roma is the original and current name in Italian of Rome city!). The "O" of Roma was replaced by the Colosseum, maybe the most famous symbol of my city. The author of the Colosseum image is Stefano Linguerri; some time ago he created it for the JUG Roma logo.
The selected font for the Logo is, obviousy, the Times New Roman ;-)
Do you like it?
Comments about the Logo are welcome in this post.
Monday, March 19, 2007
Roma supports portlets!
Roma Framework support the Portlets! They are not JSR-168 portlets but just POJO that are rendered as seperated-independent boxes. You can move the portlets around your desktop ala Google Personalized Homepage. Each box lives independently from others. Very cool!
I've adjusted the Roma Test Presentation demo application to use this feature.
Below a screenshot:
I've adjusted the Roma Test Presentation demo application to use this feature.
Below a screenshot:
Tuesday, March 13, 2007
From Jakarta Common Logging to SLF4J: NDC is missed?
Reading the Sergio's blog I wrote down to avoid to use Jakarta Common Logging APIs (JCL) in favour of Simple Logging Facade For Java (SLF4J)
I decided to refactor all Roma Framework in support of SLF4J, but I'm surprised to not find an interface for Log4J Nested Diagnostics Contexts (NDC)!!! NDC is a static class that allows to track user session information in Log4J.
So now Roma Echo2 module will depend by SLF4J and Log4J directly. Tomorrow I'll write a generic interface to abstract NDC behaviour + Log4J implementation. Does SLF4J guys will appreciate this contribute? We'll see ;-)
I decided to refactor all Roma Framework in support of SLF4J, but I'm surprised to not find an interface for Log4J Nested Diagnostics Contexts (NDC)!!! NDC is a static class that allows to track user session information in Log4J.
So now Roma Echo2 module will depend by SLF4J and Log4J directly. Tomorrow I'll write a generic interface to abstract NDC behaviour + Log4J implementation. Does SLF4J guys will appreciate this contribute? We'll see ;-)
Subscribe to:
Posts (Atom)