Hi,
> I have a design problem. In my system there is a instance, which contains
> the a dependancy table, which will be read and modified very intensively by
> other beans at runtime.
> 1. If I just forget any multiple VM problem and model it as a singelton
> class(not a bean), can I use synchronize keyword to make the class thread
> safe? I don't think there is a security policy concerning using of
> synchronization, so I am not sure, how the app server can check it?
I feel quite sure that you can legally do this. The Vector class is
synchronized, and it's used all the time in EJB apps. The EJB 1.1 spec
says in section 18.1.2 (programming restrictions) that you mustn't use
the synchronized keyword "to synchronize execution of multiple [bean]
instances". But that doesn't mean that you can't use synchronized to
make one particular non-bean object thread-safe.
In a single JVM situation, (1) will work fine. If you move to multiple
JVMs, you can make your object an RMI (or CORBA) server and store it on
one of your machines.
> 2. If I do model this instance as a bean, the only possibility I have is to
> treat it like a entity bean, which doesn't synchronize its state with any
> database.
This would work too. Depending on your situation, this may be easier to
do than (1) above. But it's a heavyweight solution for what you really
need.
> 3, I know there were attempts to introduce a singelton bean type. Is it
> possible toimplement it myself without the support of singelton bean through
> the app server?
As Evan and Victor recently pointed out, no, you can't without making
certain assumptions about your app server and machine configuration.
cheers,
david
--
David Sims [EMAIL PROTECTED]
Sims Computing, Inc. www.simscomputing.com
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
