Shafique Razzaque

In reply to Ner min's comment:

The only drawback would be:
Every Concrete Component will also have to write the getDescription() method.

I find your topic rather interesting.

Here's my input:

Its pretty clear that you need to 'bookmark' the state of the application (or you may call saving of the session) and return to it. You should be using the Memento Pattern to do this.

Now, about your implmentation choices, I have a few suggestions:

1. Identify 'savepoints' until which the session can be saved and the user may be able to resume the operation from this 'savepoint' on his subsequent logins. This helps you define and scope the objects you need to worry about saving, and hence makes life easier for your design.

2. Once identified, all objects must adhere to a uniform interface. this allows easier saving and reloading(using factory/builder) of the objects.

3. identify the pages which are supported for resumption of session. Do not allow saving of session (state) across all pages on the applications.

4. Persist your state using database.

5. Users may/maynot return back to their persisted states, leading to maintainance nightmares of bulk of records (or states). So, make life easier by housekeeping the state, meaning each state will expire unless used within a timeperiod. Use an expireDate (default to 30 days) for each saved state.

Do post your comments and feedbacks on this topic, I am interested to know about your final choice of design (and its implementation flavours).

Regards,

My input on this topic:

The reason description method has an implmentation in the base class (Beverage) is becoz: all the Concrete Components (Expresso, HouseBlend etc) need not override it. Description is a simple method all ConcreteComponents may simply inherit and reuse without any change.

However the example shows us to decorate the description and cost(in ConcreteDecorators). So, to enforce the ConcreteDecorators to implement their own getDescription method..it is made abstract in the Decorator interface (CondimentDecorator).

As for the getCost method, it needs to be overriden at all ConcreteComponents and decorated at the ConcreteDecorators. Hence it is made abstract at the base class itself (at Beverage).

Hope it clarifies your doubt.

Cheers,
Shafique Razzaque,
Singapore.

Good score..Congratulations.

Congratulations....good score.

Thats a good score. Well done.

Congratulations, well done.

Congratulations Sunitha. Well done.

Hi all,
This morning I scored 98% in SCBCD exam.
Here is my input for those who are preparing:
1. I used EJB specs, studied it thrice only.
2. I used WhizLabs exam simulator for a week before the exam.
3. I used the inputs from this forum consistently.
I firmly believe that EJB specs are more than enough for covering the subject. Also, they are perfectly detailed and provide a technical view of the subject.
An exam simulator is sure to give you an extra edge. Whizlabs simulator is good, it helped me figure out my skills in the respective topics. My score on Whizlabs simulator was ranging from 85% to 89%.
The SCBCD exam turned out to be tougher than what I expected. The questions took longer to answer, I just managed to finish the 70 questions in time. The only question I made a mistake was on Environment Entries.
Thank you all of you, for being a part of this dynamic and ever growing online community.
Now its time for me to open my SCEA books
[ March 21, 2004: Message edited by: Shafique Razzaque ]

Hi,
I would like to check ..does the exam interface indicates the 'number of correct answers' for any multiple choice question (for those check-box styled questions).
Thank you,
[ March 18, 2004: Message edited by: Shafique Razzaque ]

The 'purpose of the Rule' is to allow the Stateful Bean using BMT to execute multiple business methods in the same transaction.
Consider a scenario:
A stateful session Bean uses BMT. Client calls multiple methods, method_1() , method_2(), .. method_n() which are to be executed in the same transaction.
Flow:
1. Client invokes the bean's method_1().
2. method_1() has BMT demarcation to start a transaction T_1 using UserTransaction.begin().
3. method_1() returns without completing transaction T_1.
4. method_2() is called next, since T_1 is already associated with the instance the method executes in transaction T_1.
5. method_2() returns without completing the transaction.
6. method_n() is the last to be called, it continues in T_1, and eventually commits/rollbacks the transaction T_1 using UserTransaction.commit().
Conditions:
a. If method_2() ( or method_n() ) attempts to open a new transaction in the above scenario, when T_1 is already open and has not been commited, it will throw javax.transaction.NotSupportedException in the UserTransaction.begin() method.
b. Stateless Beans are however required to complete the transaction before the business method returns (unlike Stateful Session Beans).
Note: If the client calls the method_1() in his own transaction , the client's transaction is always suspended before BMT starts its own transactions.
I hope it answers your question.
Regards,
Shafique.
[ March 03, 2004: Message edited by: Shafique Razzaque ]