Well, last time I used this title I got some useful comments. Meanwhile I fixed my problems and in fact it was a race condition that I couldn't fix by using locks.
The problem I was facing had to do with the fact that I have a graph of objects that I maintain in a database. Adding a new object to the graph, means that certain objects would point to it as being a new neighbor. Which objects in the graph would get a new neighbor is determined by an algorithm that ensures that this process is 'fair' to the other objects in the graph.
When two or more objects are added more or less simultaneously to the graph, my algorithm would do the same thing and select the same objects that would receive a neighbor. One might argue that the system on this topic is truly stateless.
Anyway, I tried to fix my algorithm to not always pick the same neighbors, that didn't work. I tried to change my datamodel such that the system would be a little more lightweight, that obviously didn't work either. I tried to work with locks which ensured consistency in my model, but still no scalability on this end. I did some tweaking with transaction-scope and that fixed some issues. But finally I realized that I needed the EJB 3.1 Singleton which is not available in 3.0 so I mimicked part of its functionality by introducing a synchronized block on the smallest piece of code that suffered from the concurrency. This together with a smaller transaction scope fixed the problem.
But since that doesn't give me that warm and fuzzy feeling. Especially not since I know there's a solution in EJB 3.1, I'm now considering moving to GF 3 and use EJB 3.1 features. Of course all thru NetBeans' support for GF3 and EJB 3.1.
I'll keep you posted.
Iwan
Showing posts with label JavaEE. Show all posts
Showing posts with label JavaEE. Show all posts
Wednesday, August 19, 2009
Monday, July 27, 2009
Why Netbeans rules Glassfish... racing got me to this conclusion
Hi,
Last weekend I ran into this race-condition on the server side of our game IFF (plug: http://www.sticktailgames.com:8080/IFFMobile/). I was stress testing the server and what do you know, all crumbled into a pile of rubbish as soon as, dare I say, more than one person at a time registered for the game. Now I do have made some short-cuts in the server code to circumvent some code because I want to test a lot, and don't want to have to wait if I don't have to. So entering an activation code on your mobile was taken out of the equation. Anyway, the problem is there and since I do expect some time in the future that two or more people register at the same time, I wanted this to be solved.
As it turned out, there was a race-condition; two processes were fighting for the same record in the database and that turned into an inconsistent state of the data. And since inconsistency in the database is worse than a crashing system that at least is consistent so I can start it up again... It turned out that this little piece of concurrency could be turned into a little piece of sequency and all would work out really nice. So how do you control this? I thought about using a queue to list the requests for a unique record in the database. Since the requests would be handled sequentially I would be out of the woods. A message queue is easily created and NB created all code, including the creation of the server resources for my MDB, queue etc.
Proper code generation is sooooo convenient.
But I needed to revert a lot of code this weekend to a state prior to the weekend, and that included my messaging stuff. Turns out, the resources NB generated in Glassfish v2.1 didn't want to move. Every attempt to delete them turned into an error message, stating that the resource could not be deleted as it was used in server server.
From the GF output in NB: Validation error: [ADMVAL1052: Element connector resource 'jms/iffBaseGenerationTopicFactory' can not be deleted because it is referenced from server 'server']
Not from NB nor from Glassfish' own admin console I couldn't delete the created ConnectionFactory. I had to open domains/domain1/config/domain.xml and delete the lines referring to my ConnectionFactory.
Once I found out how to remove the JMS resources I could get back on track. Now I'm back at solving my race-condition. Still thinkering on how to handle this. Probably I need to ensure that there'll be only one connection possible to the queue. So only one MDB can access the queue and handle the message. Any other approaches are appreciated in the comments of this post.
Iwan
Last weekend I ran into this race-condition on the server side of our game IFF (plug: http://www.sticktailgames.com:8080/IFFMobile/). I was stress testing the server and what do you know, all crumbled into a pile of rubbish as soon as, dare I say, more than one person at a time registered for the game. Now I do have made some short-cuts in the server code to circumvent some code because I want to test a lot, and don't want to have to wait if I don't have to. So entering an activation code on your mobile was taken out of the equation. Anyway, the problem is there and since I do expect some time in the future that two or more people register at the same time, I wanted this to be solved.
As it turned out, there was a race-condition; two processes were fighting for the same record in the database and that turned into an inconsistent state of the data. And since inconsistency in the database is worse than a crashing system that at least is consistent so I can start it up again... It turned out that this little piece of concurrency could be turned into a little piece of sequency and all would work out really nice. So how do you control this? I thought about using a queue to list the requests for a unique record in the database. Since the requests would be handled sequentially I would be out of the woods. A message queue is easily created and NB created all code, including the creation of the server resources for my MDB, queue etc.
Proper code generation is sooooo convenient.
But I needed to revert a lot of code this weekend to a state prior to the weekend, and that included my messaging stuff. Turns out, the resources NB generated in Glassfish v2.1 didn't want to move. Every attempt to delete them turned into an error message, stating that the resource could not be deleted as it was used in server server.
From the GF output in NB: Validation error: [ADMVAL1052: Element connector resource 'jms/iffBaseGenerationTopicFactory' can not be deleted because it is referenced from server 'server']
Not from NB nor from Glassfish' own admin console I couldn't delete the created ConnectionFactory. I had to open domains/domain1/config/domain.xml and delete the lines referring to my ConnectionFactory.
Once I found out how to remove the JMS resources I could get back on track. Now I'm back at solving my race-condition. Still thinkering on how to handle this. Probably I need to ensure that there'll be only one connection possible to the queue. So only one MDB can access the queue and handle the message. Any other approaches are appreciated in the comments of this post.
Iwan
Monday, November 26, 2007
NB 6.0 RC2, Getting there... but still WS code generation issues.
Hi,
Recently I blogged about the RC1 of NetBeans I installed and the good and bad of the first release candidate. of NetBeans 6.0. One of the major upgrades of NetBeans since about ever.
I installed RC2 last week right after it came out and started testing the major bug I was experiencing, WS client generation for mobile applications. And the bug I'd found was solved, and I was very happy about that. Although it got a bit of a disappointment not long after this 'Yippie' feeling. Issue 122702 is the new code generation problem around the block when it comes to generating code for mobiles to connect to a WS. The problem is that when a class of my own is the type of a field of another class of my own and that second class is produced or consumed by a WS operation, the code for that class is not generated by NB, at least not by either RC1 or RC2. The class that should be generated is fairly simple to create myself, but that is mainly because it is a simple class, well at least the one I created for this issue. Mobility and WS support are definitely an area not yet much treaded.
There's another issue I have with the whole WS connectivity code generation issue, which is that NB generates code that already exists. So it doesn't have to generate the code at all. From a compatibility concern between WS server and WS client, I use exactly the same code on both ends. Therefore I have a mobile-library project setup that is used by my JavaME project as well as my JavaEE project. In this library all classes are defined that are used in the WS communication layer, thus ensuring that the phone sends across data that can be handled by the server and vice versa. This is probably not necessary, but has saved me loads of headaches, since I am now confident that I only send data across that can be handled by both ends. No classes that are too advanced for JavaME so to speak. All classes are there, but NB refuses to use them and generates classes of its own and uses them.
The interesting part here is that when generating a mobile client to web application, the package hierarchy as well as the classnames generated are the same as those found in my web application, i.e. the shared library mentioned above, so I can just delete these generated versions of my classes and use the right classes instead.
When generating a mobile WS client, the package hierarchy and the class names differ. Which makes it harder to replace the generated classes with my own created classes. Really mind boggling is the fact that the standard naming convention 'MyClass' is donned for 'myClass', which looks exactly like the field naming convention utilized by most developers I know.
But mind, I didn't get any exception pop-ups at all since installing RC2, the IDE is rather responsive, more than RC1 I think. And overall it is becoming a solid product, at least from my point of view. Me being a developer working on a mobile massive multi-user online realtime strategy game (MMMORSG).
Iwan
Recently I blogged about the RC1 of NetBeans I installed and the good and bad of the first release candidate. of NetBeans 6.0. One of the major upgrades of NetBeans since about ever.
I installed RC2 last week right after it came out and started testing the major bug I was experiencing, WS client generation for mobile applications. And the bug I'd found was solved, and I was very happy about that. Although it got a bit of a disappointment not long after this 'Yippie' feeling. Issue 122702 is the new code generation problem around the block when it comes to generating code for mobiles to connect to a WS. The problem is that when a class of my own is the type of a field of another class of my own and that second class is produced or consumed by a WS operation, the code for that class is not generated by NB, at least not by either RC1 or RC2. The class that should be generated is fairly simple to create myself, but that is mainly because it is a simple class, well at least the one I created for this issue. Mobility and WS support are definitely an area not yet much treaded.
There's another issue I have with the whole WS connectivity code generation issue, which is that NB generates code that already exists. So it doesn't have to generate the code at all. From a compatibility concern between WS server and WS client, I use exactly the same code on both ends. Therefore I have a mobile-library project setup that is used by my JavaME project as well as my JavaEE project. In this library all classes are defined that are used in the WS communication layer, thus ensuring that the phone sends across data that can be handled by the server and vice versa. This is probably not necessary, but has saved me loads of headaches, since I am now confident that I only send data across that can be handled by both ends. No classes that are too advanced for JavaME so to speak. All classes are there, but NB refuses to use them and generates classes of its own and uses them.
The interesting part here is that when generating a mobile client to web application, the package hierarchy as well as the classnames generated are the same as those found in my web application, i.e. the shared library mentioned above, so I can just delete these generated versions of my classes and use the right classes instead.
When generating a mobile WS client, the package hierarchy and the class names differ. Which makes it harder to replace the generated classes with my own created classes. Really mind boggling is the fact that the standard naming convention 'MyClass' is donned for 'myClass', which looks exactly like the field naming convention utilized by most developers I know.
But mind, I didn't get any exception pop-ups at all since installing RC2, the IDE is rather responsive, more than RC1 I think. And overall it is becoming a solid product, at least from my point of view. Me being a developer working on a mobile massive multi-user online realtime strategy game (MMMORSG).
Iwan
Subscribe to:
Posts (Atom)