Hi Richard,
This has raised something that has been in the back of my mind for sometime.
I have been waiting for this opportunity to kick it off - thanks May. What
has been bugging me is that I felt that with the cmp contract and the
various optimizations been provided that there was something missing to
handle this "typical case". The problem below is that usually in the case of
read only access your code will produce an error unless we know that it has
been modified. The read-only access by an user will incorrectly set the
"last updated" and "last updated by" field in the bean and overwite the last
real update. Now before WebLogic starts screaming YES, YES I still think
that the isModified method call is still not the way to go. I am bit low on
coffee at the moment so I will leave it up to others to come up with better
ways to solve this problem. The solutions proposed will probably include
1. Using a session bean to do the updating of beans with the necessary
setting of the two fields - in this case the session bean is in control.
This is probably the simplest design.
2. The cmp entity contract is further elaborate to provide hooks into some
mechanisms one being has something changed.
3. Use a method like isModified to determine whether to set these values in
your ejbStore
4. Flag the fields in the bean descriptor that basicall says ignore these
fields when determining storage needs. In the ejbStore set these values.
5. Flag the fields in the bean descriptor that basically says if changed
detected in the other fields then set values. This is really getting silly.
6. Promote these properties to the context. The reason for this thought is
that what happens during a transaction and somebody accesses the beans
isLastUpdated methods. Is the return of the previous value correct here or
should it already reflect the current status in the transaction. What does
all this mean? Maybe promoting to the context class it allows for bean
designer to interface with the cmp engine. The bean designer has the ability
to publish this in the beans interface by using this interface.....OK I am
rambling but I hope your getting the drift.
.....
....come on give me more solutions or tell me to have more coffee and think
clearer. I am probably missing something here.
kind regards
William Louth
> -----Original Message-----
> From: Richard Monson-Haefel [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, May 01, 2000 10:50 PM
> To: [EMAIL PROTECTED]
> Subject: Re: CMP Entities - logging changes to attributes?
>
> Hi May,
>
> If I understand you correctly you want to get the identity of the caller,
> which
> can be obtained using the EJBContext as follows:
>
> public class MyBean implements EntityBean {
> public int something;
> public double somethingelse;
> public long timestamp;
> public String callerID;
>
> public EntityContext ejbContext;
>
> public void setEntityContext(EntityContext cntxt){
> ejbContext = cntxt;
> }
>
> public void ejbStore( ){
>
> Principal principal = ejbContext.getCallerPrincipal();
> callerID = principal.getName();
>
> timestamp = System.currentTimeMillis();
> ...
> }
> ...
> }
>
> Of course, the Principal is not necessarily the same as the person running
> the
> application. It all depends on how you set up your security environment,
> but if
> you know your target environment and how Principal maps to authenticated
> users,
> then this should work fine.
>
> Richard
>
> May Charles N wrote:
>
> > In our design we have specified a CMP attribute on each of our entity
> beans
> > which preserves the id and time of the last user to issue an update.
> >
> > What I would like to know is how to extract this information and where
> to
> > set this particular attribute. I presume it should be set just before or
> in
> > ejbStore(). Extracting the time is trivial, using
> > System.currentTimeMillis(). How can I determine the user's id? I presume
> > this can't be done on the database end, because the database only knows
> that
> > the EJB container is posting changes, not the
> > individual user. So how does one do it in the Bean class?
> >
> > (The views represented in this message are my own, and do not
> necessarily
> > represent the views of my employer).
>
> ==========================================================================
> =
> 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".
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
===========================================================================
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".
