Serializing processing with EJBs

[Mark Herschberg]

Background...
Another questions about my trading application. We support multiple securities, all of which are traded concurrently. I have one session bean (OrderCrosserBean) in particular which takes an order and fills it. There are multiple instances of this bean on the server. We want two people trading different securities to be able to trade at once, i.e. bean instances working in parallel. However, two people trading in the same security should not have their orders done in parallel. The processing of the second should not begin until the first order is completeled.
I would normally create a lock and synchronize on it, but I have a feeling that's a no-no in EJB land. What's the right way to do this?
--Mark

[Kyle Brown]

The problem is that you can't guarantee that using MDB's in EJB unless you somehow throttle the thread pool size of the MDB down to one. That's probably not a good idea.
In fact the way this is usually handled is through locking the database with a "select for update" or similar kind of statement.
Kyle

[Mark Herschberg]

Currently there are entity beans in a large table. That is all limit orders for all securities are in one big table; so locking the subset for that particular security could work. However, I'm hoping to move away from the DB completely for this. Any ideas for other means?
--Mark

[Chris Mathews]

The database would be the most natural and easiest place to manage this lock. Why are you moving away from databases again?
I think you could go with an in-memory lock, probably implemented as a Singleton. The real reason Singletons are frowned upon in J2EE is two-fold:
1) Global variables are generally bad.
2) Singletons don't play nice in clusters.
However, it is obvious that that no matter how the lock is implemented, it must be globally accessible to all EJBs if it is to be effective.
If you really wanted to follow J2EE Dogma then you could create your lock and access it through JNDI. However, I don't think that this additional complexity is actually going to gain you anything...
I was just thinking of a really nasty way this could be done using the Command Pattern and a bunch of Entity Beans Lock Managers (one for each security). However, I won't say anything else for fear of retribution from Kyle.
[ March 13, 2003: Message edited by: Chris Mathews ]

[Kyle Brown]

Originally posted by Chris Mathews:
The database would be the most natural and easiest place to manage this lock. Why are you moving away from databases again?
I think could go with an in-memory lock, probably implemented as a Singleton. The real reason Singletons are frowned upon in J2EE is two-fold:
1) Global variables are generally bad.
2) Singletons don't play nice in clusters.
However, it is obvious that that no matter how the lock is implemented, it must be globally accessible to all EJBs if it is to be effective.
If you really wanted to follow J2EE Dogma then you could create your lock and access it through JNDI. However, I don't think that this additional complexity is actually going to gain you anything...
I was just thinking of a really nasty way this could be done using the Command Pattern and a bunch of Entity Beans Lock Managers (one for each security). However, I won't say anything else for fear of retribution from Kyle.

No need to fear that. I think you've already explained why it's such a bad idea adequately enough.
Go with the database locks. It's the cleanest all around.
Kyle

[Mark Herschberg]

Well, the reason I'm moving away from them is... well, it doesn't seem like I should've used them to begin with. The code that crosses orders is the key piece of the system. It should be very very fast. I misunderstood its implementation earlier and replied on the database to lock individual limit orders (e.g. "sell 100 shares once the price hits $50"). However, I no longer need to worry about contention for inidividual limit orders, the lock is for all orders in a security at once.
At this point, why even keep them in the database? I should just keep all the orders in memory directly. Sure the system may crash and we lose orders, but that's no a significant problem.
Basically, there's no inherent need for the database. I'll use it to lock if I have to, but somehow, it seems like a bad design to put things into a database just to use it for locking (kinda like using my car to keep my wallet safe--its works, but not the best way to use a car or protect my wallet).
--Mark

[Kyle Brown]

OK, following with that analogy, would you put a big 1/2 pound padlock through your pants pocket and your wallet to keep it safe? Seems like the car is a better alternative...
Kyle

[Mark Herschberg]

Originally posted by Kyle Brown:
OK, following with that analogy, would you put a big 1/2 pound padlock through your pants pocket and your wallet to keep it safe? Seems like the car is a better alternative...
Kyle

Um, I was thinking of the analogy more like this...
Why use a car? You use it to get around. While it can serve as a vault, it's probably better to use it as a vechicle, and get a lockbox for the wallet.
Why use a database? Well it was designed for persistent storage (server fialure, or shutdown). I don't need persistent storage. Why even use a database if I don't need to?
--Mark

[Nitzan Levi]

hi,
you can use a statefull session bean that will do the orders , the OrederCrosserBean will get the handle to this statefull from the jndi(only when it realy needs it) , and if another OrederCrosserBean instance is currently working with this statefull then the container will throw you an exception. then you can deside if you want to try untill the statefull will be free or not !

[Mark Herschberg]

Originally posted by nitzan levi:
hi,
you can use a statefull session bean that will do the orders , the OrederCrosserBean will get the handle to this statefull from the jndi(only when it realy needs it) , and if another OrederCrosserBean instance is currently working with this statefull then the container will throw you an exception. then you can deside if you want to try untill the statefull will be free or not !

This sounds possible. How exactly does this work? Do I create one stateful session bean for each security? If I have two OrderCrosserBeans fighting for contention of the stateful session bean, is there anyway I can insure ordering, i.e. that the first OrderCrosserBean to try to get the stateful session bean will get it first, even if it's waiting along with others.
--Mark

[Kyle Brown]

You would have to create a different crosserbean for each security -- and that's a lot of beans...
Isn't the database starting to sound like a good idea yet
Kyle

[Sudd Ghosh]

From my past experience, and a lot of appl tuning experience, I feel that database should be the last resort for doing any temporary storage. Whatever can be done in memory should be done that way. If one doesn't have to worry about losing some temporary info, memory storage should be the way. Even if one has to go the extra mile using beans, that should be preferred. Database should be used only for some permanent storage requirement from which some other appl will benefit.
The reason is, DB access will always remain slower as compared to memory access.
Thanks, Sudd

[Kyle Brown]

Originally posted by Sudd Ghosh:
From my past experience, and a lot of appl tuning experience, I feel that database should be the last resort for doing any temporary storage. Whatever can be done in memory should be done that way. If one doesn't have to worry about losing some temporary info, memory storage should be the way. Even if one has to go the extra mile using beans, that should be preferred. Database should be used only for some permanent storage requirement from which some other appl will benefit.
The reason is, DB access will always remain slower as compared to memory access.
Thanks, Sudd

"Premature Optimization is the Root of All Evil" -- C.A.R. Hoare
What Mark is talking about is building a distributed, fail-safe locking mechanism. One of these already exists in every database. Why not TRY it with the database and see if the performance is acceptable? You could find out in an hour, and possibly avoid DAYS worth of coding.
Kyle

[Sudd Ghosh]

I don't deny what you said. But here is another familiar and modified one:
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
- Donald Knuth
He actually modified the one from CAR Hoare.
This specifically says "forget about small efficiencies" which typically tends to get "bigger" when we talk about database traffic, disk I/O and remote calls. The inefficiencies are "small" as long as it only concerns good programming habits/OOP/and use of good design patterns.
So my take is if you can live with database then do it that way and keep it simple/maintainable, otherwise just avoid database and use memory wherever you can. Do the extra work if that's what is needed to sell the product. Anyway, it is a good idea to think ahead of the real-time transaction volume in production.
Thanks

[Chris Mathews]

Sudd Ghosh said:
So my take is if you can live with database then do it that way and keep it simple/maintainable, otherwise just avoid database and use memory wherever you can. Do the extra work if that's what is needed to sell the product. Anyway, it is a good idea to think ahead of the real-time transaction volume in production.
In this case, using the database will keep the system much more maintainable, then writing a custom built solution. Sure, there may be some additional overhead but:
1) You don't know how much until you profile.
2) Likely the performance is going to be "good enough".
Premature optimization results in hard to maintain code that may or may not even perform well.
Remember that the majority of our bottlenecks are found in the minority of our code. Without profiling, we are just shooting in the dark.