And here is a sample from a DAO the loads the session:
http://code.google.com/p/ezmodeler/source/browse/branch/i4c_lpp/data/org/i4change/app/data/project/daos/ProjectDaoImpl.java

The thing is: To implement this all DAOs/Management classes have to be
loaded using Spring Injection.
All those Singleton-Methods *getInstance* in each class should be removed
and replaced by Spring configuration. Only if you do that you can use this
pattern and let spring organize the session.

Maybe there is a semi solution to load / inject the SessionTemplate into the
DAOs directly, but I think the way in my samples is the standard way to do
it.

Sebastian

2011/8/1 [email protected] <[email protected]>

> Here is the sample:
>
>
> http://code.google.com/p/ezmodeler/source/browse/branch/i4c_lpp/WebContent/WEB-INF/applicationContext.xml
>
> See the *txProxyTemplate* ...
>
> and then in every (ROOT-)Service this proxy Template is injected, for
> example:
>
> http://code.google.com/p/ezmodeler/source/browse/branch/i4c_lpp/WebContent/WEB-INF/services/diagramservice.service.xml
>
> You have to generate Interfaces for the Service Classes to make it work:
>
> http://code.google.com/p/ezmodeler/source/browse/branch/i4c_lpp/src/app/org/i4change/app/remote/IDiagramservice.java
>
> Sebastian
>
>
>
> 2011/8/1 Василий Дегтярев <[email protected]>
>
>> Hello Sebastian,
>>
>> Could you please give me link of samples of implementation from another
>> project.
>>
>> Thanks,
>> Vasiliy.
>>
>>
>> 2011/7/29 [email protected] <[email protected]>
>>
>>> That sounds good.
>>>
>>> Additionally the best way to handle the Session itself would be to let
>>> Spring manage the Session.
>>> Its a bit of refactoring to do it because in the end all Classes should
>>> be injected via Spring so that you can use a Spring template that holds the
>>> SessionContext and inject it into every Class. I can link some samples of
>>> such implementation from another project of mine.
>>>
>>> Sebastian
>>>
>>>
>>> 2011/7/29 Vasya <[email protected]>
>>>
>>>> Hello Sebastian,
>>>> It seems that we should improve openjpa transaction because current
>>>> transaction implementation does not catch openjpa entity transaction
>>>> exceptions. So we propose to add special DAOTransaction class that
>>>> should catch transaction exception and rollback transaction, please
>>>> see example below:
>>>>
>>>> public abstract class DAOTransaction <T>  {
>>>>
>>>>
>>>>        private T result;
>>>>        private EntityManager em;
>>>>
>>>>        public DAOTransaction() {
>>>>        }
>>>>
>>>>        public T execute() throws Exception {
>>>>                Object idf = PersistenceSessionUtil.createSession();
>>>>                em = PersistenceSessionUtil.getSession();
>>>>                EntityTransaction transaction = em.getTransaction();
>>>>                if (!transaction.isActive()) {
>>>>                        transaction.begin();
>>>>                }
>>>>                try {
>>>>                        run();
>>>>                        transaction.commit();
>>>>                }
>>>>                catch (Exception e) {
>>>>                        e.printStackTrace();
>>>>                }
>>>>                finally {
>>>>                if (transaction.isActive()){
>>>>                    transaction.rollback();
>>>>                }
>>>>                        PersistenceSessionUtil.closeSession(idf);
>>>>            }
>>>>                return result;
>>>>        }
>>>>
>>>>        public abstract void run();
>>>>
>>>>        public void setResult(T result_) {
>>>>                result = result_;
>>>>        }
>>>>
>>>>        public T getResult() {
>>>>                return result;
>>>>        }
>>>>
>>>>        public EntityManager getEntityManager() {
>>>>                return em;
>>>>        }
>>>>
>>>> }
>>>>
>>>>
>>>> In this case method Usermanagment.addUser looks like this:
>>>>        public Long addUser(final Users usr) {
>>>>                try {
>>>>                        return new DAOTransaction<Users>() {
>>>>                    public void run() {
>>>>                                setResult(getEntityManager().merge(usr));
>>>>                    }
>>>>                }.execute().getUser_id();
>>>>
>>>>                } catch (Exception ex2) {
>>>>                        log.error("[addUser]", ex2);
>>>>                }
>>>>                return null;
>>>>        }
>>>>
>>>> Please let me know your opinion about this.
>>>>
>>>> Thanks,
>>>> Vasiliy.
>>>>
>>>>
>>>> On Jul 27, 2:14 pm, "[email protected]" <[email protected]>
>>>> wrote:
>>>> > I agree with you with some exceptions:
>>>> >
>>>> > Users can login with the login+pwd OR email+pwd, both is accepted.
>>>> >
>>>> > If you query the database for the login, you have to check if
>>>> externalUserId
>>>> > == null.
>>>> > Cause the login and email is only unique for those people that sign up
>>>> > through openmeetings. If you sign up by using Facebook, Moodle,
>>>> Joomla,
>>>> > whatever (generally using the SOAP/REST API), you can simulate any
>>>> user and
>>>> > those users "Could" use all the same login/email. So you might have
>>>> 1000
>>>> > times the same login/email, cause for example somebody uses the SOAP
>>>> API,
>>>> > always sets the same login/email but NEVER an externalUserId (this
>>>> would
>>>> > result in creating a new user in openmeetings every time). As those
>>>> users
>>>> > that are simulated for access via SOAP are not allowed to login via
>>>> the
>>>> > login-shield it does not matter that the login/email is several times
>>>> > duplicated.
>>>> >
>>>> > So you should change your patch to use the same mechanism that I use
>>>> for
>>>> > checking login+email+externalUserId==null.
>>>> >
>>>> > I just do realize that this check is wrong :))
>>>> >
>>>> > The mechanism should be:
>>>> > If the imported user has externalUserId != null / > 0 => the user
>>>> should be
>>>> > imported WITHOUT checks. Even if duplicated.
>>>> > If the imported user has exteranlUserId == null, then you have to
>>>> query the
>>>> > database if a user with login or email and externalUserId=null does
>>>> already
>>>> > exist, and if so you can use your logic "if user was found we map all
>>>> > events/rooms etc. to user found"
>>>> >
>>>> > 2011/7/27 Maxim Solodovnik <[email protected]>
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > > Hello Sebastian,
>>>> >
>>>> > > Today I planed to check in the code for handling login/emails and
>>>> files
>>>> > > (written and tested by Vasiliy), but found you was ahead of me :)
>>>> >
>>>> > > Your code is slightly differs than ours so I that to ask couple of
>>>> > > questions:
>>>> > > in your code you skip import user data (for all users) if user email
>>>> is
>>>> > > found in the DB.
>>>> > > In our approach we check user login (since email is not required
>>>> field and
>>>> > > )
>>>> > > and if user was found we map all events/rooms etc. to user found.
>>>> >
>>>> > > I think our code will better suite the following situation:
>>>> > > 1) OM server was installed and full of data (users, organizations,
>>>> events
>>>> > > etc.)
>>>> > > 2) All data was backed up
>>>> > > 3) New version was installed (new DB)
>>>> > > 4) While installation admin entered his username/email (used in the
>>>> old
>>>> > > installation) To make situation more complicated lets imaging the
>>>> system has
>>>> > > more than one admin. Backup/Restore was done by user with "old" id
>>>> not equal
>>>> > > to 1.
>>>> >
>>>> > > As a result user data will not be mapped to the only created admin
>>>> user.
>>>> >
>>>> > > Does it make sense to you?
>>>> > > Could you take a look at the Vasiliy's patch attached (against rev.
>>>> 4007)?
>>>> >
>>>> > > On Mon, Jul 25, 2011 at 14:13, [email protected] <
>>>> > > [email protected]> wrote:
>>>> >
>>>> > >> I have done some tests during the weekend.
>>>> > >> I have some minor changes to the import, the memory consumption was
>>>> > >> okay, with Xmx512MB the was no Heap-Space exception. I will commit
>>>> my
>>>> > >> changes tonight but it should be no problem to merge them if you
>>>> have
>>>> > >> updates too, you can proceed in commiting them.
>>>> > >> The folder renaming, I had no chance to look inside that yet.
>>>> >
>>>> > >> .. as well as the activity window.
>>>> >
>>>> > >> You can also see the renewed proposal for Apache incubation here:
>>>> >
>>>> > >>
>>>> http://mail-archives.apache.org/mod_mbox/incubator-general/201107.mbo.
>>>> ..
>>>> >
>>>> > >> Sebastian
>>>> >
>>>> > >> 2011/7/22 [email protected] <[email protected]>:
>>>> > >> > The only problem I see are the login/email cause:
>>>> > >> > Login should be unique so that users can login.
>>>> > >> > We just simply might add a check on that value and skip that user
>>>> if
>>>> > >> > it already exists.
>>>> > >> > Cause otherwise you always have at minimum one duplicate:
>>>> > >> > The user with the ID=1, cause even if you import it directly
>>>> after you
>>>> > >> > did the installation, ONE user always is there. And it would be
>>>> bad to
>>>> > >> > duplicate that one, cause you would not be able to login with
>>>> this
>>>> > >> > (Admin) user again.
>>>> >
>>>> > >> > Sebastian
>>>> >
>>>> > >> > 2011/7/22 Maxim Solodovnik <[email protected]>:
>>>> > >> >> Hello All,
>>>> > >> >> I have checked in the code with id maps, discussed earlier.
>>>> > >> >> It has no check for duplicate users (import done multiple times)
>>>> > >> >> I'm not sure how can we protect the DB from such user action
>>>> ....
>>>> > >> >> Even if all data would be checked it would not work in following
>>>> > >> situation:
>>>> > >> >> 1) import was performed
>>>> > >> >> 2) some data was edited (using admin)
>>>> > >> >> 3) import was run one more time
>>>> > >> >> Maybe you have any ideas about it?
>>>> > >> >> On Fri, Jul 22, 2011 at 17:42, [email protected] <
>>>> > >> [email protected]>
>>>> > >> >> wrote:
>>>> >
>>>> > >> >>> Okay Vasya,
>>>> >
>>>> > >> >>> regarding the ZIP for the 40.000 Users....this import is not
>>>> the usual
>>>> > >> >>> test-case
>>>> >
>>>> > >> >>> I do not export the Files in it, cause that would result in a
>>>> 80GB ZIP
>>>> > >> >>> file. I do only import/export the database-record in the ZIP. I
>>>> have
>>>> > >> >>> added some option for that.
>>>> > >> >>> You should generate some sample data with some sample rooms.
>>>> >
>>>> > >> >>> From what I understood your import would allow users to import
>>>> the
>>>> > >> >>> same ZIP n-times.
>>>> > >> >>> Or do you add some checks to not duplicate it?
>>>> >
>>>> > >> >>> What happens to users if you import a user twice, cause the
>>>> > >> >>> username/login would exist two times and the Auth-Mechanism
>>>> would not
>>>> > >> >>> work anymore. I think for a phase1 its okay if that fails,
>>>> somebody
>>>> > >> >>> should know that importing the same ZIP twice can result in
>>>> duplicates
>>>> > >> >>> ...
>>>> >
>>>> > >> >>> Sebastian
>>>> >
>>>> > >> >>> 2011/7/22 Vasya <[email protected]>:
>>>> > >> >>> > Hello Sebastian,
>>>> >
>>>> > >> >>> > I have added mapping for ID’s for import. Maxim should be
>>>> submitted
>>>> > >> my
>>>> > >> >>> > changes today.
>>>> > >> >>> > Now I am working on copy the folder of the upload-directory
>>>> from the
>>>> > >> >>> > Backup-ZIP to the disk.
>>>> >
>>>> > >> >>> > Vasiliy.
>>>> >
>>>> > >> >>> > On Jul 21, 4:21 pm, "[email protected]" <
>>>> [email protected]>
>>>> > >> >>> > wrote:
>>>> > >> >>> >> Hi Maxim,
>>>> >
>>>> > >> >>> >> yes this was the thing that I tried to avoid :) Collecting
>>>> all IDs
>>>> > >> and
>>>> > >> >>> >> building lookup tables to see which old id corresponds to
>>>> the
>>>> > >> record
>>>> > >> >>> >> after the import.
>>>> >
>>>> > >> >>> >> The other thing, to import the objects in the correct order
>>>> is
>>>> > >> already
>>>> > >> >>> >> implemented.
>>>> >
>>>> > >> >>> >> Some Issue will be also the uploaded files: There are some
>>>> > >> >>> >> restrictions on the user's profile images. I think they have
>>>> the
>>>> > >> >>> >> userId as folderName in the path. So you can't copy the
>>>> folders
>>>> > >> >>> >> anymore into the disk just by coping the ROOT folder of the
>>>> > >> >>> >> upload-directory from the Backup-ZIP to the disk, cause
>>>> there are
>>>> > >> some
>>>> > >> >>> >> subfolders that contain invalid folderNames that need to be
>>>> > >> >>> >> rewritten/renamed.
>>>> >
>>>> > >> >>> >> We can try that out, its obviously better if it works but
>>>> its a
>>>> > >> rather
>>>> > >> >>> >> big change.
>>>> > >> >>> >> My concern is the same like yours: Could be quite memory
>>>> hungry
>>>> > >> >>> >> process.
>>>> >
>>>> > >> >>> >> I got for example a database with 40.000++ users that I need
>>>> to
>>>> > >> >>> >> import/export. Holding all 40.000 users would not work,
>>>> maybe
>>>> > >> holding
>>>> > >> >>> >> the 40.000 IDs could work.
>>>> >
>>>> > >> >>> >> Sebastian
>>>> >
>>>> > >> >>> >> 2011/7/21 Maxim Solodovnik <[email protected]>:
>>>> >
>>>> > >> >>> >> > Hello Sebastian, Vasiliy
>>>> > >> >>> >> > Instead of creating generator classes I would like to
>>>> propose the
>>>> > >> >>> >> > following
>>>> > >> >>> >> > mechanism:
>>>> > >> >>> >> > 1) Import should be done in "well known" order i.e.
>>>> > >> organisanisations
>>>> > >> >>> >> > are
>>>> > >> >>> >> > imported first then users, then rooms etc.
>>>> > >> >>> >> > 2) While importing certain object id is not set. Instead
>>>> of this
>>>> > >> old
>>>> > >> >>> >> > id and
>>>> > >> >>> >> > new id are stored in hashtable key== oldId, value == newId
>>>> > >> >>> >> > 3) While importing objects containing links to "parent
>>>> objects"
>>>> > >> newId
>>>> > >> >>> >> > is
>>>> > >> >>> >> > used using Hashtable created.
>>>> > >> >>> >> > 4) Pictures/streams/videos are stored in the file system
>>>> using
>>>> > >> newId
>>>> > >> >>> >> > The import will be memory consuming operation but all
>>>> constraints
>>>> > >> >>> >> > will be
>>>> > >> >>> >> > valid.
>>>> >
>>>> > >> >>> >> > On Mon, Jul 18, 2011 at 17:46, Vasya <
>>>> [email protected]>
>>>> > >> >>> >> > wrote:
>>>> >
>>>> > >> >>> >> >> Hi Sebastian,
>>>> >
>>>> > >> >>> >> >> Thanks for your answer!
>>>> >
>>>> > >> >>> >> >> I will continue to investigate problem tomorrow.
>>>> >
>>>> > >> >>> >> >> Vasiliy.
>>>> >
>>>> > >> >>> >> >> On Jul 18, 5:32 pm, "[email protected]" <
>>>> > >> [email protected]>
>>>> > >> >>> >> >> wrote:
>>>> > >> >>> >> >> > Hi Vasya,
>>>> >
>>>> > >> >>> >> >> > If tested getBackupRooms yesterday, it was okay for me.
>>>> >
>>>> > >> >>> >> >> > The thing with the *deleted* is that it has to return
>>>> ALL
>>>> > >> records,
>>>> > >> >>> >> >> > no
>>>> > >> >>> >> >> > matter if  the deleted flag is set or not.
>>>> > >> >>> >> >> > This is the case because of the foreign key references.
>>>> >
>>>> > >> >>> >> >> > Just imagine the following sample:
>>>> > >> >>> >> >> > Rooms-Table:
>>>> > >> >>> >> >> > ID name deleted
>>>> > >> >>> >> >> > 1  room1 false
>>>> > >> >>> >> >> > 2  room2 true
>>>> > >> >>> >> >> > 3  room3 false
>>>> >
>>>> > >> >>> >> >> > Rooms-Organizations Table:
>>>> > >> >>> >> >> > ID rooms_id organisation_id
>>>> > >> >>> >> >> > 1  1             1
>>>> > >> >>> >> >> > 1  2             2
>>>> > >> >>> >> >> > 1  3             1
>>>> >
>>>> > >> >>> >> >> > If you only export those records that are deleted ==
>>>> 'false'
>>>> > >> >>> >> >> > => the importer would add room3 as the record with the
>>>> ID 2
>>>> > >> and as
>>>> > >> >>> >> >> > consequence the room would be assigned to the
>>>> organization 2
>>>> > >> =>
>>>> > >> >>> >> >> > which
>>>> > >> >>> >> >> > is wrong of course.
>>>> >
>>>> > >> >>> >> >> > And the same you have between all tables. That is why I
>>>> did
>>>> > >> import
>>>> > >> >>> >> >> > records always WITH all records marked as "deleted" AND
>>>> in the
>>>> > >> >>> >> >> > import
>>>> > >> >>> >> >> > process I did add each object with the ID ALREADY SET.
>>>> That
>>>> > >> means
>>>> > >> >>> >> >> > I
>>>> > >> >>> >> >> > did not use the generated Id from Hibernate, I did use
>>>> the ID
>>>> > >> that
>>>> > >> >>> >> >> > was
>>>> > >> >>> >> >> > provided
>>>> >
>>>> > ...
>>>> >
>>>> > read more »
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "OpenMeetings developers" group.
>>>> To post to this group, send email to [email protected].
>>>> To unsubscribe from this group, send email to
>>>> [email protected].
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/openmeetings-dev?hl=en.
>>>>
>>>>
>>>
>>>
>>> --
>>> Sebastian Wagner
>>> http://www.webbase-design.de
>>> http://openmeetings.googlecode.com
>>> http://www.wagner-sebastian.com
>>> [email protected]
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "OpenMeetings developers" group.
>>> To post to this group, send email to [email protected].
>>> To unsubscribe from this group, send email to
>>> [email protected].
>>> For more options, visit this group at
>>> http://groups.google.com/group/openmeetings-dev?hl=en.
>>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "OpenMeetings developers" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected].
>> For more options, visit this group at
>> http://groups.google.com/group/openmeetings-dev?hl=en.
>>
>
>
>
> --
> Sebastian Wagner
> http://www.webbase-design.de
> http://openmeetings.googlecode.com
> http://www.wagner-sebastian.com
> [email protected]
>



-- 
Sebastian Wagner
http://www.webbase-design.de
http://openmeetings.googlecode.com
http://www.wagner-sebastian.com
[email protected]

-- 
You received this message because you are subscribed to the Google Groups 
"OpenMeetings developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/openmeetings-dev?hl=en.

Reply via email to