🔒 Locked

[java] EJB programming restrictions..

Started by stubble Dec 1, 2004 at 6:46 AM 6 replies 1.6k views

Original Post

Dec 1, 2004 at 6:46 AM

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

wondersonic

Dec 1, 2004 at 7:27 AM

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

CaptainJester

101

CaptainJester

Dec 1, 2004 at 7:32 AM

Quote:
Original post by stubble- non thread management

The container creates and manages a pool of threads. This pool may grow or shrink at any time and out of your control. If you create your own threads, you may cause an out of memory error by having too many threads in existence, because the container cannot account for your threads. The VM on the other hand has a fixed number of known threads.

Quote:
Original post by stubble- no synchronisation

Don't know.

Quote:
Original post by stubble- no non-final statics

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.

redmilamber

Dec 1, 2004 at 7:57 AM

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 :(.

stubble

Author

stubble

Dec 1, 2004 at 8:55 AM

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

wondersonic

Dec 1, 2004 at 10:05 AM

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? :)

seanw

Dec 1, 2004 at 10:12 AM

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.

CaptainJester

101

CaptainJester

Dec 1, 2004 at 1:48 PM

Quote:
Original post by seanw
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.

Too true.

Quote:
Original post by stubble
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.

They apply to all classes because all classes run within the server's container. Not just servlets and EJBs. Therefore the container resource pool is affected by every class that you run.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.