Tuesday, October 31, 2006

Why primitive types are unprecises? the unacceptable explaination...

Another excellent article by Brian Goetz on numerical java data type storing. It's just a question of IEEE 754. So, don't expect to work with primitive types in Java for finacial applications. Such a pity! My old Casio FX-7000 is more powerfull than my computer.

Financial programs represents a major part of softwares all over the world. If you want my opinion, its unacceptable to have to work with wrapped types!!!

James Goslin, any solution? You're welcome if you have one.

http://www-128.ibm.com/developerworks/java/library/j-jtp0114/

Friday, October 27, 2006

Open ESB

Great news,

I just learnt that Sun launched an open source ESB project with a tool suite for NetBeans. This fact of having developped graphical tools to design processes and mappings is a very (VERY) important point in my point of view. Something tells me that, if the product is well done, the situation will be harder for webMethods in several months.

I will publish my Violet UML Editor as quickly as possible to investigate on it.

http://www.netbeans.org/kb/55/bpel_gsg_project.html

http://open-esb.dev.java.net/

Thursday, October 12, 2006

Searching files on unix

Want to find files and perform massives operations on them, here are tws sample commands for unix platforms :

find -name "[filename]"

find -name "[filename]" -exec [command] '{}' \;

where [filename] and [command] should be replaced by real values. [command] is another unix command to execute on each file found. The file found is represented by '{}' in the command to execute. \; indicates to end of the command.

Ex : find -name "*.tmp" -exec rm '{}' \; -> deletes all tmp files.

Thursday, October 05, 2006

CVS activity : extract history for a user and from a date

cvs -d :pserver:[user]@[server]:/[repository] log -d ">2006-09-28" -w[user]

where
[user] is the username
[server] your server location
[repository] the CVS repositpry url

Of course, don't forget to change the date!

Monday, October 02, 2006

Hibernate 3 and Oracle 9i cursors : how does it work?

Here is a post I found on the hibernate forum. It explains why cursors opened are not released on session.close() :

OK. Here's the result of this thread:

For the environment, JDK1.4.2_01, Oracle 9i server, oracle 9i jdbc driver (ojdbc14.jar) and oci connection to the database (not thin driver);

There's no problem with hibernate's prep stmt cache nor with Oracle Jdbc driver with regard to cursors remaining open after Session.close().

Every Session.iterate() and Session.load() calls cause a prep stmt to be created on the server side. And after you close the session with Session.close(), hibernate explicitly calls appropriate driver methods to close the resultsets and prepared statements.

However, after you close the session, you won't see the cursors de-allocated (or closed) on the server side. While it seems to be a bug, it actually is not. The driver maintains a list of prep statements and open cursors in its memory and as soon as you re-use the same connection by opening a session on that very same connection, you'll see that the previous cursors and prep statements will go away.

To check this behaviour, open a session, run a few Sesson.load(), Session.iterate() methods and then call Session.close(). Run the below query and you'll see that the cursors are still there (in the statistic 'opened cursors current').

select n.*,s.* from v$sesstat s, v$statname n where s.statistic#=n.statistic# and sid=23 and n.name like '%cursor%'

However, in the same program, after the above calls, if you
call SessionFactory.getSession() and grab the same jdbc connection from the pool;
as soon as you call Session.load() or Session.iterate(), you'll see that the number of open cursors will be 0 or decrease dramatically. This means that the jdbc driver is smart enough to track the status of the cursor and prep stmt and reports the closed cursors in the next round-trip to the database, hence reducing network round-trips, which is a good thing for performance.

Regards,
Bulent Erdemir