I believe, I do need the synchronized capability not only for private case
but also for public methods in session EJB.
I created an "almost real life" scenario that illustrates the need for synch
capability.
You can read the code but here summary.
I have a designed a class (Complex) that was to be used by multiple
threads.
The class Complex has own variables, which are not stored in database.
I have two threads that theoretically could be on different machines and
know nothing about each other.
Consequently, I implemented "set" and "print" methods with synch.
If I did not, I could get inconsistent results.
Now my boss came to me and said that she wants the class to be implemented
as EJB service.
Since I am lazy, I took easy approach and implented the service as:
ServiceClass extends OriginalClass implements SessionBean.
Now my clients can find the EJB service and call the methods of the
OriginalClass
which are synched.
Question:
It should be legal for two clients to access concurrently
ServiceClass(session bean).
Assuming that it is legal for two clients to access a single ServiceClass,
how do we enforce
the critical section within the ServiceClass.
Any ideas?
Here I enclose a pseudocode to illuminate the issue:
(note that -- introduces a comment)
--plain class.
--This is somewhat artificial class to demonstrate a point.
--Requirements on this class are:
--1. maybe called by multiple threads concurrently.
--2. must give consistent results.
//
--setVal() and print() are synchronized because
--I want to be able to use this class by multiple threads, say C1, and C2.
--It stands to reason, that one day, C1 will be suspended
--in the middle of setVals after setting "real" but before setting imag.
--At that time by coincidence, C2 will try to print the Complex.
--In that scenario, the data will be inconsistent,
--that is to say, C2 will print <new real, old imag>.
--I hope nobody objects to having synchronized in this case.
import java.io.*;
public class Complex
{
private int real;
private int imag;
public Complex()
{
real = 0;
imag = 0;
}
public synchronized void setVals(int r, int i)
{
real = r;
imag = i;
}
public synchronized void print()
{
System.out.println("real=" + real);
System.out.println("imag=" + imag);
}
}
--ComplexService.java
--My boss came to me and said that she wants the Complex class to be EJB.
--I decided to take least amount of effort path.
--I converted class Complex into EJB service (SessionBean).
import javax.ejb.*;
import java.io.*;
import java.util.*;
import java.rmi.*;
public class ComplexService extends Complex implements SessionBean
{
private transient SessionContext ctx;
private transient Properties props;
public ComplexService()
{
super();
}
public void ejbActivate()
{
}
public void ejbRemove()
{
}
public void ejbPassivate()
{
}
public void ejbCreate()
{
}
public void setSessionContext(SessionContext ctx)
{
this.ctx = ctx;
}
}
--ComplexClient
--Note that I have two of these, C-1 runs on one machine
--C-2 runs on another machine.
--The implications are, that C-1 and C-2 don't know about each other
--just like any other good processes in distributed system.
import ComplexServiceHomeIF;
import ComplexServiceRemoteIF;
import java.rmi.*;
import java.io.*;
import java.util.*;
import javax.naming.*;
public class ComplexClient
{
public static void main(String [] args)
{
try
{
InitialContext ictx = new InitialContext();
ComplexServiceHomeIF home = (ComplexServiceHomeIF)
ictx.lookup("ComplexServiceHome");
ComplexServiceRemoteIF remote = home.create();
--now imagine I have two clients doing this loop.
--C-1 and C-2.
--These two clients live on two different machines and know
--nothing about each other.
--It stands to reason, that one day, C-1 will be suspended
--in the middle of setValues after setting "real".
--At that time by coincidence, C-2 will try to print the
Complex.
--In that scenario, the data will be inconsistent,
--that is to say, C-2 may print <300, 450>.
for (int i = 0; i < 1000000; i++)
{
remote.setValues(i, i);
remote.print();
}
remote.remove();
}
catch(Exception ioex)
{
;
}
}
}
----- Original Message -----
From: Kirk Pepperdine <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 11, 2000 10:02 AM
Subject: Re: having a PRIVATE synchronized method in a session EJB
> I believe the restriction is against threading. Given this, there is
> no need to synchronize.
>
> Kirk
>
>
> -----Original Message-----
> From: David Olivares <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Date: Monday, January 10, 2000 7:52 AM
> Subject: having a PRIVATE synchronized method in a session EJB
>
>
> >hi there,
> >I need to have a PRIVATE synchronized method in a session EJB. I know the
> specs don't allow me to have a synchronized methods in EJBs, but I'm not
> sure if having a PRIVATE synchronized method is also forbidden. A way
> around this will be to have a helper class that does the synchronization
for
> me, which I think is allowed in the specs.
> >thanks in advanced
> >David :)
> >
>
>===========================================================================
> >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".
>
>
===========================================================================
> 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".
>
===========================================================================
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".
