Hi guys This isn't directly game related (apologies). I'm writing some Java threading guidelines with a colleague and, since most of our code runs in an EJB container, an important section relates to the (threading) restrictions placed on EJB programming. Specifically: - non thread management - no synchronisation - no non-final statics I understand the reasoning behind these and I'm pushing to include them in our guidelines. However there is always the (nonsensical to me) argument that the EJB restrictions only apply to the EJB code itself and not any classes deployed with and used by it (in many cases the majority of the EJB's implementation - in our case ALL of it). A supporting argument to this is that the JDK itself breaks all of these restrictions - but must by definition be used in an EJB's implementation. Although the JDK argument is a tough one to counter - I believe it comes down to the JDK and Container being implemented by the same vendor - the vendor knows their implementations and therefore will have addressed any issues. We don't and shouldn't know their implementation so should stick to the restrictions. Not ideal - but sometimes you have to accept things like this. So - any thoughts on this? I've searched for a definitive answer on this - but would be interested in any links people have too. cheers Stubble

Instead of EJB search for Spring (IoC), hibernate and POJO.

Also read the EJB 2.1 spec about job and works... (don't remember the exact terms).

WS

Incidentally, this is why we gave up on J2EE as entirely useless for games development 4 years ago. You have so little control over the environment, and so many restrictions; where this may be bearable for simplistic business logic it's intolerable for high-performance systems like MMOG's :(.

cheers guys - as I said I understand why each restrictions applies and how to justify each one in an EJB - but I was having problems convincing my peers that they apply to classes deployed with and used by the EJB too.

My main problem was finding somewhere that said "the restrictions apply to classes used by the EJB too" - the spec seems to miss this important clarification which some people use as a reason to ignore the restrictions by putting all their logic in a POJO and calling it from the EJB. This makes no sense to me - but I needed to justify it to my colleagues.

If anyone is interested I found something which says what I wanted:

http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html

thanks

Quote:Original post by redmilamber
Incidentally, this is why we gave up on J2EE as entirely useless for games development 4 years ago. You have so little control over the environment, and so many restrictions; where this may be bearable for simplistic business logic it's intolerable for high-performance systems like MMOG's :(.

And so, what type of architecture did you propose for such games in the past? And what do you propose now? :)

Quote:Original post by CaptainJester
This relates to different users will be served by different instances of the same servlet. If you use statics, they can clobber each other. Since final statics are immutable, they cannot be changed, so there is no danger.

Not to be pedantic, but some people forget that "final static X = new Y()" means that the reference X will always points to Y, but not that Y cannot be changed. You can only guarentee this if Y is immutable.