----- Original Message -----
From: Robert Silverman <[EMAIL PROTECTED]>
To: A mailing list for Enterprise JavaBeans development
<[EMAIL PROTECTED]>
Sent: Thursday, March 16, 2000 8:38 PM
Subject: Re: Re: having a PRIVATE synchronized method in a session EJB
> 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".
