Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (540)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Forcing J2EE Servlets to be single-threaded?  (Read 1500 times)
0 Members and 1 Guest are viewing this topic.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Posted 2005-07-30 21:10:21 »

I'm doing some code conversion to J2EE compatibilty, and some classes require that they be executed with the guarantee only one outstanding thread is ever accessing them. They can process incoming requests asynchronously, by queuiing them up. They use a very fine-grained asynch exec model, so that all this happens efficiently (think of DMA...).

This is problematic, since J2EE doesn't (IIRC) allow single-thread-only access to any servlet, which means I will have to jump through hoops within the servlet to try and guarantee it - throw exceptions in constructors to try and prevent the things being created - etc. I've never tried to do this in J2EE that I can remember, so maybe there's some simple way I'm just ignorant of.

These classes work fine in the grexengine (which just has a flag to enable this for a given component!), but rather than have to port or rewrite the code to make it also execute under J2EE I'd like to find some clean way of making it work. Any ideas?

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #1 - Posted 2005-07-30 21:13:54 »

PS: the best hack I can think of so far is:

1. Have a single static variable which is some object.
2. Have the main service() method of the servlet wait() on that object's monitor
3. When servicing is complete, notify()

So, I will have some (possibly huge depending upon how crap the J2EE container is) number of instances of each servlet, but they will be stuck on monitors and only one will be allowed to execute at once. My experience of monitors these days is that they're fast enough that this should not impact performance too much even under high load

...but life would be much easier if there were some feature in J2EE that I could invoke to prevent this wasteful blocking Sad.

malloc will be first against the wall when the revolution comes...
Offline ap_kelly

Junior Devvie




Java rocks!


« Reply #2 - Posted 2005-07-31 02:50:41 »

The Servlet specification defines the following interface for single threaded servlets

SingleThreadServlet

Any servlet that implements this interface (it's a marker interface so no methods need defining), is guaranteed to be thread safe.

http://www.unix.org.ua/orelly/java-ent/servlet/ch03_04.htm

Andy.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #3 - Posted 2005-07-31 10:38:51 »

Thanks. I knew about STS, but it only goes halfway to what I want - it doesn't prevent additional instances from being created - although I was being dumb in not thinking of using that instead of monitors. I'll still need to make everything static Sad but it's better than nothing.

malloc will be first against the wall when the revolution comes...
Offline Sakazaki

Junior Newbie





« Reply #4 - Posted 2005-08-01 07:59:14 »

I don't know what exactly you want to do in your servlet; I think you use it like a door for some kind of service call.
So, if this is your environment, maybe you can use a service locator.
You may use Spring like service locator in your web app (service class is singleton by default in Spring).
Your servlets get the service instance from Spring, and it serve to you a shared instance.
It is not important that your servlet is a singleton instance, isn't his nature; move logic in external class, outside the J2EE behavior, and maybe you get the point.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Mr.CodeIt (23 views)
2014-12-23 03:34:11

rwatson462 (53 views)
2014-12-15 09:26:44

Mr.CodeIt (45 views)
2014-12-14 19:50:38

BurntPizza (85 views)
2014-12-09 22:41:13

BurntPizza (110 views)
2014-12-08 04:46:31

JscottyBieshaar (78 views)
2014-12-05 12:39:02

SHC (89 views)
2014-12-03 16:27:13

CopyableCougar4 (96 views)
2014-11-29 21:32:03

toopeicgaming1999 (155 views)
2014-11-26 15:22:04

toopeicgaming1999 (152 views)
2014-11-26 15:20:36
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!