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

JavaME in NB 6.7

NetBeans 6.7 has been out in the wild for a while now and... well and then there's the JavaME stuff, which is kinda important to me since we're developing mobile games (we = Sticktail Games). JavaME SDK 3.0 is finally out the door and pre-packaged with NB 6.7, but still no support on other platforms than Windows. Which until last Christmas wasn't a big deal, but I got a MacBook 13" from misses Santa and would've liked native support for all my tooling... bummer. I'll have to invest in some VirtualBox stuff to get the ME parts running. Any tutorial to get this going is appreciated, but please JavaME SDK 3.0 Team: Get the other platforms done as well. PLEASE.

There's another gripe with the new tooling: I can't open my NB mobility projects in the SDK tooling, since the NB libraries for SVG and others aren't included in it. And there's no easy way to get those libraries in. Major bummer in my opinion, especially since the SDK 3.0 tooling supports for example the WURFL database. Which is nowhere to be found in NB 6.7 although the SDK 3.0 is included and supported as the default emulator, replacing the WTK.

While using the SDK I ran a couple of times in the issue that there wasn't enough memory for my MIDlet suite to be installed, although it installed nicely in the WTK 2.5.2 emulator. And there's no option to increase the size of the emulators heap.

But all in all, the new tooling is superb. Debugging is going a lot smoother now and especially the hot-deploy support is excellent. A real time saver. But ultimately nothing beats testing on an actual device, and the promise of better on-device-debugging support is great. Now we just need to get it working. In a usable fashion. So:

Nokia, Sony-Ericsson, Samsung, LG, HTC and all of you other vendors, please work on this. As long as you're putting in those nasty bugs in your JavaME implementation, we need to test on your devices. I'm okay in getting some different phones to test on, but help me out here as well.

Iwan

It's been a while, we're now at 6.7

Hi,

It's been a while since I've been posting about NetBeans, all kinds of reasons, but mainly because I just couldn't give blogging enough priority. But today I've got some spare minutes.

NetBeans has been growing tremendously since the last time I blogged about it, we're now at 6.7.

I think last time I was blogging about NetBeans I was working on a game, for mobiles. I should check my posts... anyway, what I can tell you is that other than previous experiences with new versions of NB, I've been able to open the project in new versions, even daily builds without experiencing major incompatibilities. Once or twice I wasn't able to also open the project in the old version again. This is of course a major achievement but more over, it makes testing NetBeans a better experience.

So what else are some highlights:
- When uninstalling, there now is an option to also uninstall the userdir. Excellent.
- UML support is about to be dropped, at least it's no longer maintained according the WIKI. Boooh
-The GF2.1 installation from previous versions of NB is no longer recognized and you'll be asked to install a new version. When not selecting to do so, NB does see your old installation and it all works. Confusing
- Woodstock is dropped (JSF components that at least look decent) and is (going to be) replaced by IceFaces. Mildly boooh.

Iwan