RE: offtopic question
It seems that now the latest MySql version (v.3.23.39) supports transactions. I have just tested it and everything seems to work fine. Regards, Vilavanh -Message d'origine- De : Lorenz, Manfred [mailto:[EMAIL PROTECTED]] Envoyé : 12 juillet, 2001 11:43 À : '[EMAIL PROTECTED]' Objet : AW: offtopic question You're not right. In the documentation about mysql i found the following: By default, MySQL runs in autocommit mode. This means that as soon as you execute an update, MySQL will store the update on disk. If you are using transactions safe tables (like BDB, InnoDB, you can put MySQL into non-autocommit mode with the following command: SET AUTOCOMMIT=0 After this you must use COMMIT to store your changes to disk or ROLLBACK if you want to ignore the changes you have made since the beginning of your transaction. If you want to switch from AUTOCOMMIT mode for one series of statements, you can use the BEGIN or BEGIN WORK statement: BEGIN; SELECT @A:=SUM(salary) FROM table1 WHERE type=1; UPDATE table2 SET summmary=@A WHERE type=1; COMMIT; Note that if you are using non-transaction-safe tables, the changes will be stored at once, independent of the status of the autocommit mode. If you do a ROLLBACK when you have updated a non-transactional table you will get an error (ER_WARNING_NOT_COMPLETE_ROLLBACK) as a warning. All transactional safe tables will be restored but any non-transactional table will not change. If you are using BEGIN or SET AUTOCOMMIT=0, you should use the MySQL binary log for backups instead of the older update log. Transactions are stored in the binary log in one chunk, upon COMMIT, to ensure that transactions which are rolled back are not stored. See section 23.4 The Binary Log. There are some alternative table formats, with which you can have transactions with mysql nowadays. Regards Manfred -Ursprüngliche Nachricht- Von: Renzo Toma [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 12. Juli 2001 10:46 An: [EMAIL PROTECTED]; Aapo Laakkonen; [EMAIL PROTECTED] Betreff: RE: offtopic question You're right: MySQL does not have transactional support and does only do table locking (no row-locking like the big boys). -Original Message- From: Aapo Laakkonen [mailto:[EMAIL PROTECTED]] Sent: woensdag 11 juli 2001 18:45 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: offtopic question > message: transaction isolation levels not supported. > > That let me suppose that both MS Access and MySql jdbc drivers do not > support yet well the rowset package. I think that access and mysql doesn't support transactions or they do not support the isolation level that was requested by your application. ANSI SQL defines 4 isolation levels and if application wants to have let's say committed read isolation level and db doesn't support it or doens't support higher isolation levels (e.g. repeatable read or serializable) then they need to abort the transaction. Access is kind of one man db and it doesn't support transactions I think, but I'm not sure about MySQL, but what I can remember is that it doesn't support transactions.
AW: offtopic question
You're not right. In the documentation about mysql i found the following: By default, MySQL runs in autocommit mode. This means that as soon as you execute an update, MySQL will store the update on disk. If you are using transactions safe tables (like BDB, InnoDB, you can put MySQL into non-autocommit mode with the following command: SET AUTOCOMMIT=0 After this you must use COMMIT to store your changes to disk or ROLLBACK if you want to ignore the changes you have made since the beginning of your transaction. If you want to switch from AUTOCOMMIT mode for one series of statements, you can use the BEGIN or BEGIN WORK statement: BEGIN; SELECT @A:=SUM(salary) FROM table1 WHERE type=1; UPDATE table2 SET summmary=@A WHERE type=1; COMMIT; Note that if you are using non-transaction-safe tables, the changes will be stored at once, independent of the status of the autocommit mode. If you do a ROLLBACK when you have updated a non-transactional table you will get an error (ER_WARNING_NOT_COMPLETE_ROLLBACK) as a warning. All transactional safe tables will be restored but any non-transactional table will not change. If you are using BEGIN or SET AUTOCOMMIT=0, you should use the MySQL binary log for backups instead of the older update log. Transactions are stored in the binary log in one chunk, upon COMMIT, to ensure that transactions which are rolled back are not stored. See section 23.4 The Binary Log. There are some alternative table formats, with which you can have transactions with mysql nowadays. Regards Manfred -Ursprüngliche Nachricht- Von: Renzo Toma [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 12. Juli 2001 10:46 An: [EMAIL PROTECTED]; Aapo Laakkonen; [EMAIL PROTECTED] Betreff: RE: offtopic question You're right: MySQL does not have transactional support and does only do table locking (no row-locking like the big boys). -Original Message- From: Aapo Laakkonen [mailto:[EMAIL PROTECTED]] Sent: woensdag 11 juli 2001 18:45 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: offtopic question > message: transaction isolation levels not supported. > > That let me suppose that both MS Access and MySql jdbc drivers do not > support yet well the rowset package. I think that access and mysql doesn't support transactions or they do not support the isolation level that was requested by your application. ANSI SQL defines 4 isolation levels and if application wants to have let's say committed read isolation level and db doesn't support it or doens't support higher isolation levels (e.g. repeatable read or serializable) then they need to abort the transaction. Access is kind of one man db and it doesn't support transactions I think, but I'm not sure about MySQL, but what I can remember is that it doesn't support transactions.
RE: offtopic question
You're right: MySQL does not have transactional support and does only do table locking (no row-locking like the big boys). -Original Message- From: Aapo Laakkonen [mailto:[EMAIL PROTECTED]] Sent: woensdag 11 juli 2001 18:45 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: offtopic question > message: transaction isolation levels not supported. > > That let me suppose that both MS Access and MySql jdbc drivers do not > support yet well the rowset package. I think that access and mysql doesn't support transactions or they do not support the isolation level that was requested by your application. ANSI SQL defines 4 isolation levels and if application wants to have let's say committed read isolation level and db doesn't support it or doens't support higher isolation levels (e.g. repeatable read or serializable) then they need to abort the transaction. Access is kind of one man db and it doesn't support transactions I think, but I'm not sure about MySQL, but what I can remember is that it doesn't support transactions.
Re: offtopic question
I don't think MS Access and MySql support the transaction levels that a CachedRowSet needs. I know that MS Access can't support EJBs for this reason. David --- Vilavanh Messien <[EMAIL PROTECTED]> wrote: > Hi all, > > I am currently building a web application with > Struts and I am facing the > following problem. > I am using the CachedRowSet class to retrieve data > from my database. > Actually, I have no trouble when I perform a SELECT > query. However, when I > perform an UPDATE, DELETE or INSERT query, I get the > following error > message: transaction isolation levels not supported. > > This exception seems to be thrown only with MS > Access and MySql databases. > With Oracle, no exception is thrown and everything > seems to work fine ... > > That let me suppose that both MS Access and MySql > jdbc drivers do not > support yet well the rowset package. Has anyone ever > had such experience of > this issue ? or could anyone give me some > explanations ? > > Thanks in advance, > > Vilavanh Messien > > > __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
Re: offtopic question
> message: transaction isolation levels not supported. > > That let me suppose that both MS Access and MySql jdbc drivers do not > support yet well the rowset package. I think that access and mysql doesn't support transactions or they do not support the isolation level that was requested by your application. ANSI SQL defines 4 isolation levels and if application wants to have let's say committed read isolation level and db doesn't support it or doens't support higher isolation levels (e.g. repeatable read or serializable) then they need to abort the transaction. Access is kind of one man db and it doesn't support transactions I think, but I'm not sure about MySQL, but what I can remember is that it doesn't support transactions.
offtopic question
Hi all, I am currently building a web application with Struts and I am facing the following problem. I am using the CachedRowSet class to retrieve data from my database. Actually, I have no trouble when I perform a SELECT query. However, when I perform an UPDATE, DELETE or INSERT query, I get the following error message: transaction isolation levels not supported. This exception seems to be thrown only with MS Access and MySql databases. With Oracle, no exception is thrown and everything seems to work fine ... That let me suppose that both MS Access and MySql jdbc drivers do not support yet well the rowset package. Has anyone ever had such experience of this issue ? or could anyone give me some explanations ? Thanks in advance, Vilavanh Messien
Re: Actions - design question + an offtopic question
wow.thanks for the explanation!! joe
Re: Actions - design question + an offtopic question
Malcolm Davis wrote: > This "Security" issue has always bothered me. > The servlet API provides a Form Based Authentication via 'j_username' and ' > j_password'. > Tomcat supports this feature, but I don't see it in Struts. > > Are there plans to support Form Based Authentication via 'j_username' and ' > j_password' In what way do you feel that Struts should support this? It's completely defined by the way you configure your web.xml file (and your server), and Struts-based applications can take advantage of that fact with no code changes at all being necessary. This is true on *any* servlet container that implements 2.2 or later, not just Tomcat. One reasonable follow-up question is "why does the example application do its own login processing?". And the answer is based on a longer discussion from earlier today -- the interface between a servlet container and the underlying database of users and roles is not portable, and I didn't want to have to research how to set that up on every single server that Struts might be run on. The whole idea of an example application is to be able to drop it in and run, as a quick test to make sure that Struts works in your environment. > > Thans, > Malcolm Craig
RE: Actions - design question + an offtopic question
This "Security" issue has always bothered me. The servlet API provides a Form Based Authentication via 'j_username' and ' j_password'. Tomcat supports this feature, but I don't see it in Struts. Are there plans to support Form Based Authentication via 'j_username' and ' j_password' Thans, Malcolm > -Original Message- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Monday, November 27, 2000 2:06 PM > To: [EMAIL PROTECTED] > Subject: Re: Actions - design question + an offtopic question > > > Joe Peer wrote: > > > hi, > > > > i just read Craig's answer to denis' question and i was > wondering if there > > is some kind of "j2ee compliant" way of doing user auth and > role-asignment - > > are there any standards one is supposed to use > > (i apologize for this offtopic question, since it's not an > struts issue, i > > guess) > > > > Well, it's not off topic if you want to use Struts-based apps in a J2EE > environment :-). > > > > > today i always use my own user/roles tables in my (relational) > database and > > i am doing all these things "by hand, means by jdbc queries" - should i > > change that? > > > > The J2EE recommendation for this is to use container-managed > security (i.e. the > elements defined in web.xml) for user > authentication and > access control. Doing so means that the container is taking care of these > issues for you, and (perhaps more importantly) that user > identities are shared > between the web layer and the EJB layer, because the server will > be using the > same underlying "database" of users and roles. > > The only downside to this approach is that there is not yet a > standardized API > for portably accessing and maintaining a "database" of users and > roles (I'm > putting "database" in quotes because the actual implementation > could be pretty > much anything, including static text files or directory servers). > > Instead, most servers provide a server-specific API to do this > kind of thing. > For example, in Tomcat you can implement an API called a Realm > that talks to > your existing database of users, and then tell Tomcat to use this Realm > implementation for user authentication. In that way, new users > added to the > database (by whatever means) become instantly authorized for web > use also. If > you were to switch to a different engine, you would need to > re-implement this > function according to the APIs provided by the new server, but > you would not > need to update your applications. > > > > > any hint / pointer to doc / suggestions would be nice! > > The API that I'm the most familiar with is Tomcat -- if you grab > the source > distribution of the "jakarta-tomcat-4.0" CVS module from > <http://jakarta.apache.org>, look in file > > catalina/src/share/org/apache/catalina/Realm.java > > for the details of what you have to implement to create your own > Realm. There > is even a provided JDBCRealm implementation that lets you connect > Tomcat to a > database already -- all you need to do is configure it in the > conf/server.xml > file, and there are several examples commented out in the stock > version of this > file. > > > > > > joe > > > > Craig > > > > > > - Original Message - > > From: Craig R. McClanahan <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Monday, November 27, 2000 6:37 PM > > Subject: Re: Actions - design question > > > > > Denis Hanson wrote: > > > > > > > Hi all, > > > > > > > > I am starting to move our existing web application to the struts > > framework > > > > and would like to ask a design question. > > > > > > > > Here's my problem. After logon, the application user is > forwarded to one > > of > > > > three screens - sysadmin, admin, user. The screen used is > determined by > > the > > > > user's role. (The three screens have no commonality, so I > don't think I > > can > > > > use the one action attrubute > shown in the > > > > example application.) > > > > > > > > I'm looking for some way to define the various paths in > > struts-config.xml so > > > > that the logon action class doesn't have hardcoded paths to > the three > > > > ro
Re: Actions - design question + an offtopic question
Joe Peer wrote: > hi, > > i just read Craig's answer to denis' question and i was wondering if there > is some kind of "j2ee compliant" way of doing user auth and role-asignment - > are there any standards one is supposed to use > (i apologize for this offtopic question, since it's not an struts issue, i > guess) > Well, it's not off topic if you want to use Struts-based apps in a J2EE environment :-). > > today i always use my own user/roles tables in my (relational) database and > i am doing all these things "by hand, means by jdbc queries" - should i > change that? > The J2EE recommendation for this is to use container-managed security (i.e. the elements defined in web.xml) for user authentication and access control. Doing so means that the container is taking care of these issues for you, and (perhaps more importantly) that user identities are shared between the web layer and the EJB layer, because the server will be using the same underlying "database" of users and roles. The only downside to this approach is that there is not yet a standardized API for portably accessing and maintaining a "database" of users and roles (I'm putting "database" in quotes because the actual implementation could be pretty much anything, including static text files or directory servers). Instead, most servers provide a server-specific API to do this kind of thing. For example, in Tomcat you can implement an API called a Realm that talks to your existing database of users, and then tell Tomcat to use this Realm implementation for user authentication. In that way, new users added to the database (by whatever means) become instantly authorized for web use also. If you were to switch to a different engine, you would need to re-implement this function according to the APIs provided by the new server, but you would not need to update your applications. > > any hint / pointer to doc / suggestions would be nice! The API that I'm the most familiar with is Tomcat -- if you grab the source distribution of the "jakarta-tomcat-4.0" CVS module from <http://jakarta.apache.org>, look in file catalina/src/share/org/apache/catalina/Realm.java for the details of what you have to implement to create your own Realm. There is even a provided JDBCRealm implementation that lets you connect Tomcat to a database already -- all you need to do is configure it in the conf/server.xml file, and there are several examples commented out in the stock version of this file. > > joe > Craig > > - Original Message - > From: Craig R. McClanahan <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, November 27, 2000 6:37 PM > Subject: Re: Actions - design question > > > Denis Hanson wrote: > > > > > Hi all, > > > > > > I am starting to move our existing web application to the struts > framework > > > and would like to ask a design question. > > > > > > Here's my problem. After logon, the application user is forwarded to one > of > > > three screens - sysadmin, admin, user. The screen used is determined by > the > > > user's role. (The three screens have no commonality, so I don't think I > can > > > use the one action attrubute shown in the > > > example application.) > > > > > > I'm looking for some way to define the various paths in > struts-config.xml so > > > that the logon action class doesn't have hardcoded paths to the three > > > role-based screens. > > > > > > Do I need to create my own ActionMapping class and add additional > > > name=/> entries, or is there some other way to do this? > > > > > > > Because we're talking about "what does the logon action forward to", you > won't > > need any additional action definitions. However, you might want some > additional > > forwards defined. For concreteness, let's assume that your three roles > are > > named "admin", "manager", and "user". > > > > One approach to this would be to define, nested within the > element for > > the login action, some forwards that are specific to only this action: > > > > > > ... > > > > ... > > type="com.mycompany.mypackage.LoginAction"> > > > > > > > > > > ... > > > > ... > > > > > > In this scenario, you can do the following at the end of the login action: > > > >
Re: Actions - design question + an offtopic question
hi, i just read Craig's answer to denis' question and i was wondering if there is some kind of "j2ee compliant" way of doing user auth and role-asignment - are there any standards one is supposed to use (i apologize for this offtopic question, since it's not an struts issue, i guess) today i always use my own user/roles tables in my (relational) database and i am doing all these things "by hand, means by jdbc queries" - should i change that? any hint / pointer to doc / suggestions would be nice! joe - Original Message - From: Craig R. McClanahan <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, November 27, 2000 6:37 PM Subject: Re: Actions - design question > Denis Hanson wrote: > > > Hi all, > > > > I am starting to move our existing web application to the struts framework > > and would like to ask a design question. > > > > Here's my problem. After logon, the application user is forwarded to one of > > three screens - sysadmin, admin, user. The screen used is determined by the > > user's role. (The three screens have no commonality, so I don't think I can > > use the one action attrubute shown in the > > example application.) > > > > I'm looking for some way to define the various paths in struts-config.xml so > > that the logon action class doesn't have hardcoded paths to the three > > role-based screens. > > > > Do I need to create my own ActionMapping class and add additional > name=/> entries, or is there some other way to do this? > > > > Because we're talking about "what does the logon action forward to", you won't > need any additional action definitions. However, you might want some additional > forwards defined. For concreteness, let's assume that your three roles are > named "admin", "manager", and "user". > > One approach to this would be to define, nested within the element for > the login action, some forwards that are specific to only this action: > > > ... > > ... > > > > > > ... > > ... > > > In this scenario, you can do the following at the end of the login action: > > String role = ... look up the role for this user ... > return (mapping.findForward(role)); > > to forward control to the menu for your user, without the action having to know > what the JSP page name is -- only the role name. > > In the example above, the forwards "admin", "manager", and "user" are defined > locally for this particular action, and are not visible to any other action. > You can also define global forwards by nesting them in the > section instead. When the findForward() method is executed, it searches first > in the local forwards for this particular action, and then in the global > forwards. > > > > > > Thanks, > > > > Denis Hanson > > Craig McClanahan > >
