We've updated our wiki software and migrated all pages from the old one (which will remain available for a while). If you see something wrong, feel free to edit.

For sometime we have been conducting ad-hoc training sessions to jPOS developers from several financial institutions in our region. We are now getting ready to host developers from locations far away from here, so we've structured 3 intense sessions that cover jPOS, Q2 and jPOS-EE in great detail. This is a nice oportunity to get up to speed with jPOS development, meet other jPOS developers and get to know what are they using jPOS for. Read the training schedule here.

/by apr/ I recently came across a java based commercial ISO-8583 encoder/decoder kind of application that claimed to perform as much as 2000 encode/decode operations per second on an average machine. Wow! that's fast! They even described their benchmark, they were talking about average messages with a 16 field set and a secondary bitmap present. It was not clear to me if they were doing both operations (encode/decode) in each cycle, or just one. I decided to give jPOS a try on an average machine [], I created a message with said number of fields, including a secondary bitmap, and a little loop including a pack and an unpack operation. I was pleased with the result: in excess 20000 pack/unpack operations per second. Then I decided to compare this same test against another commercial product, our own High performance, ISO-8583 C lightweight library. It was fast, but not as fast as I would expect, we get 40000+ pack/unpack operations per second, 2x compared to jPOS, but hey, that's C, I was expecting a 5x or 10x ratio there... The conclusions are pretty obvious to me... if you are up to, you can make Java perform slow like a turtle, and you can still charge people for it. [] Pentium 4, 1.6 Ghz, aprox 3k bogomips

For some time jpos-dev mailing list has been used for users, developers and announcements, but as the traffic is increasing there we've decided to create a user specific forum. So, welcome to jpos-users list. please read the updated mailing lists page for details.

Many jPOS based applications have to deal with accounts and have to accurately and efficiently keep track of its transactions and balances.

I found myself writing ad-hoc transaction logging software using custom database schemas and balance calculation strategies over and over, and I think this may have happened to many of you as well.

While writting custom logic is certainly a feasible option and may seem like the simplest approach, code that looks okay in a test environment may degrade once you load it with hundreds of millions of transactions.

Code that passes all tests in a development environment may encounter nasty problems under heavy load, caused by race conditions, poor performance, etc. And then you need a myriad of supporting applications for extracts, analysis, reporting, data-entry, UI, etc. that have to be customized to your unique data model.

miniGL attempts to address this problem by providing a minimalistic solution to the recurring task of safely and efficiently keeping track of accounts.

While doing so, miniGL explores the possibility of leveraging double-entry accounting methods in situations were one would tend to use just single-entry.

Read the rest here.