... I don't know what will:

And because nowadays it's modern not to steal intelectual property, here's the source of the picture.

I was unhappy with my bank (What not to do when you're a bank).

Recently, the rumors about it going bankrupt became stronger and stronger so I cashed out my accounts and went for another bank.
The rumors came out to be fake and I felt like a dumb ass, becase I followed unchecked information.

But overall I don't regret my decision. The bank now has a new software which sucks big time. I was on a few occasions unable to access my money (ATM, online, bank office), so I don't think this is a bank that I could trust.


First Investment Bank, you were one of the best, now you're one of the worst.

In a previous post (here) I spoke about having trouble with e-banking software of my bank.

There is a pretty simple solution - the online payment operator - epay.bg. It also can do bank transfers, so it's perfect for the task.

Epay can work with almost all bank cards, it's cheap, it's user-friendly, it's reliable. It's the perfect solution.
One minor drawback - it can't check balance, because for sometime now most banks don't support that feature for epay :(

Still I'm going to use it. I can check my balance using the e-banking app.

My primary bank is First Investment Bank.
I chose a quite a while ago because it had the reputation of a bank that was the first in everything.

It's e-banking was uncomparable with the competitition - outrageously ugly, but accepted smartcards and did all I wanted it to do.

Now it's getting different - they changed their system with a new one. Something called FlexCube. Weirdly enough owned by Oracle.

From internal sources I know that the new system sucks and they failed to deploy it for more than a year. And when they finally made it last week during the weekend - my bank card was not working, meaning me without access to my money just before I went to Serbia. I had to take a loan to be able to go - not a pleasant thing to do.

So about the new e-banking interface - it sucks, all my preferences and beneficients are gone. It's ugly and hard to learn.

So I'm looking for a new bank with a decent e-banking services.

I have experience with SG Expressbank and Postbank - they suck too.

Update: the comments following that post reminded me of a story:
I was in the Netherlands. Once talking to one of the guys we discussed how much cash does each of us carry. I did carry a lot, he counted on the cards he had. My case: bank cards don't work on the road, on the street, they can fail, cash cannot fail.

Later that week:
There was this friend with which we drank quite a few drinks and on the way back to the hotel (I was in an apartment, the friend in a hotel) they said the employer forgot to pay the room, so it couldn't be used. We tried all the credit/debit cards we had - no luck - none of them worked. He had to sleep at my place. Cash is bulletproof !

I spent a couple of days in Serbia. Pictures here.

Overall I was surprised by what I saw - although they are not a rich country, its visible that they are situated closer than us to the more developed countries.
They don't speed on the road, it's clean and nice and green and ordered, people are really polite, roads are so much better than the Bulgarian ones.
Overall they are more advanced than we are.

In this piece of code the task is to override system exceptions (JPA, JTA exceptions) with application exceptions:



The rewriting of PersistenceException (PE) is straightforward.
It could come from the business method (bm()) and from commit().
When it comes from commit() it is wrapped in RollbackException. Thus the if.

Unfortunately if PE is raised from the bm(), it is also raised from the commit().

So if I throw an exception at (1), it gets overridden in (2). As simple as that. Because of the finally's ability to override results (OOP got messy here).

So what should be fixed?
First, at (2) I shouldn't throw any exception.

Second, I'm thinking of checking the result of bm() - if an exception, don't call commit(), but rollback().
Sounds right.

I'm trying to like the specification, but I just can't.
Here's one more reason why:

I have SSB (Stateless Session Beans). The persistence is via JPA (implementation is Hibernate).

All my business method look something like:


I use CMT (Container Managed Transactions) which means that the container calls begin() before the method call and commit() after the method call is over.

The problem: what happens if the transaction is rolled back?

A RollbackException is thrown. It looks common sense to try to rewrite it as ApplicationException1. Well.... YOU CAN'T.

No F way (at least not an easy one).

Solution1:
Make the Beans stateful and use SessionSynchronization. UGLY - I don't want to be stateful.

Solution2:
Implement TransactionSynchronizationRegistry - just look at it.

Solution3:
Make a facade EJB that calls my own EJBs which should use requiresNew. One more level of abstraction? I have to change the contract? I don't have just one Bean, so a wrapper for every single one of them?

Solution4:
Switch back to BMT (Bean Managed Transactions) and call begin() and commit() myself. Well then the container becomes useless. But my business methods are rarely longer than a few lines, so I'm choosing this one.


CMT without any simple way to plug after commit() and this is an enterprise level spec? Really?

I'd be really happy if someone corrects me and shows me a simple way to do what I need.

I've never seen this SQL syntax:


Have you?

Here's the design:
EJBs for business logic, JPA @Enitities for object (domain) model, Web services for a public interface.

The model is quite complex.

Even in the presentation (web services) I use the entities model.

The problem comes from that in the presentation a call is made to an EJB. The EJB returns an entity which after the call is ended gets disconnected. So all collections (@OneToMany) cannot be loaded.

EAGER fetching was the solution but then half of the database was loaded on a single method call. And eventually I got to a really ugly MySQL limitation (A query with more than 61 joins (inner selects + cases + at least 40 left outer joins) and a length of 436 lines.

Now before returing the entity in the EJB method via Reflection I initialize all the collections I need. Ugly.

What I need and would perfectly fit me would be an eager fetching only until some level of deepness is reached, then switch to lazy. Then a level of 2 or 3 would be perfect.

Currently I don't of something like that existing.

If someone has an idea, please let me know.

MySQL is a RDBMS. Or at least that's what it's creators claim it to be.

There's no other self respecting database who's only engine that implements transactions (innoDB) is not created by MySQL guys. Only until recently their own engine claims to support them. Even small in-process databases like Hypersonic and Derby fully support transactions from version one. Flawlessly.

Today I found one more reason for which I think MySQL should not be put under the category RDBMS:



Until recently the maximum was only 31 table. A major WTF?!

I would gladly bet that Hypersonic and Derby do not have a constraint like that (haven't investigated it though).

The stack trace is intently complete to show that this comes from Hibernate. This can be reproduced by having a rich object model with EAGER fetching.

Maybe I'll write a little more on the EAGER fetching and the issues I have: here.

As simple as that:

Internationalization can be thought of as the design and information technology practices that enable localization to take place. It adapts products for potential use all over the world, whereas
Localization allows products to be suitable for a specific place, or “locale.”

So before thinking about localization, product and software designers must conceive the product in a way that will allow it to be later localized to many different cultures.

I got an A today in corporate finances - there was no exam, just an A for participating in classes and being memorable enough :)
Not everyone who attended all the classes was remembered - finally a reward for speaking in classes and asking dumb questions.