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.
