Fwd: OJB && struts
-- Forwarded message -- From: Behrang Saeedzadeh <[EMAIL PROTECTED]> Date: Fri, 17 Dec 2004 17:11:35 +0330 Subject: Re: OJB && struts To: [EMAIL PROTECTED] > ie Hibernate ... the only guys who managed to get it right with ORM in > the last 4 years of sun and theserverside wafflers are going to be > running the show. Incidentally I remember before Fleury was kicked off > how there was always 30 people jumping on the Entity Beans are great > bandwagon ... yeah .. I remember that one pretty well. As long as I remember Sun has always said that EJBs in general and Entity Beans in particular are not suited for every kind of application. Long ago there was a JavaWorld article named "To EJB or not to EJB" that discussed this problem and was pretty insightful. I have never liked Entity Beans too but there was a thread at TheServerSide about CMP Entity Beans and someone asked if there's any successful non trivial project based on them and some guys announced that they have built large-scale enterprise applications using CMPs for things like banking and ... and their customers were all happy and their projects successful. So yes, Entity Beans are great if used in correct places. However they had their own cons: it were possible to design a general purpose persistence layer suitable for a wider range of applications and not as difficult to understand as CMPs and Hibernate was proving instance. So they started revising the whole EJB spec and Entity Beans in particular but the goals of EJB 3.0 Entity Beans and JDO was very similar so they merged them and it will benefit from both of the strong points of Hibernate and JDO (and CMP Entity Beans if any.) However I was not talking about CMP Entity Beans. I was saying that JDO 1.0 + Externsions and JDO 2.0 is at least as good as Hibernate. I and many others () prefer it over Hibernate, you and many others don't. > The dev/community process for it should be something like this > > a) Hibernate implement it b) Jboss integrate it c) Sun accept it I don't know what are you talking about. > So it isn't really a standard then any more than hibernate is it ? > Because everyone is going > to add their little tweaks to it ... You may be right but I don't care about JDO being a standard or not. I only say that it's at least as good as Hibernate. > Is the only thing you get as standard the persistence manager interface ??? Not only the interface: the specification which includes the interface too + a reference implementation + a compatibility test kit. As long as I know many other standards (like ANSI/ISO C++, and ...) are not as broad as standards defined in the JCP. > I already use XDoclet for hibernate mapping generation, I'm talking > about the fact that your > build process now consists of the following. > > 1 Write Java file > 2 Write XDoclet mappings > 3 Run XDoclet to generate mappings ( remember it doesn't work with Java 5 ) > 4 Compile classes > 5 Run ant task to bytecode enhance > 6 Let them redeploy within tomcat or whatever > 7 Test 1, 2, 3, 4, 6, 7 are not exclusive to JDO. And using Ant, 5 does not have any noticable negative side effect. > JDO didn't make it, didn't do it right, was late for the dance and is > due to be superseded ... .. what the hell point is there in > investing time and effort in something like that ? This is your personal view point. I don't think so. > The only reason to use JDO is that you want to use Hibernate but your > boss says that you have to use something with an "(If we don't get a > clue we will go bust) Sun Microsystems" sticker on it. No. In the next project my boss has gave me the freedom to choose the persistence layer along many other things and if everything goes well I'll absolutely be using JPOX. - Behrang -- Behrang Saeedzadeh http://www.jroller.com/page/behrangsa - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: OJB && struts
-- Forwarded message -- From: Behrang Saeedzadeh <[EMAIL PROTECTED]> Date: Fri, 17 Dec 2004 17:16:22 +0330 Subject: Re: OJB && struts To: [EMAIL PROTECTED] For a list of those other people who are satisfied with JDO please have a look at this thread at TheServerSide.com: http://www.theserverside.com/news/thread.tss?thread_id=27285 -- Behrang Saeedzadeh http://www.jroller.com/page/behrangsa - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB && struts
> Incidentally EJB3 is going to be largely based on hibernate and sun > have already signaled their intention that JDO and EJB are going to be > dropped and a new standard created most likely playing catchup with > Hibernate. JDO and EJB are not going to be dropped: they're merged. The next generation persistence API for J2SE/J2EE is being designed by people from both JDO and EJB expert groups and also the lead developer of Hibernate. And JDO is already competing well with Hibernate and JDO 2.0 is very powerful and flexible. It's no longer true to say that one is better than another. From now on it's a matter of preference and fanaticism. I, myself, prefer JDO because I think it's more straightforward, easier to learn, and object oriented. Another person may feel otherwise. > Using JDO just because it is a "standard" is a bad idea, I've been > there before and have difficulty trusting anything that gets designed > by some self interested group of big companies, usually so they can > make sure that your code only works with their libraries or IDE or app > server because at the end of the day you usually have to do something > that ties you to their implementation. You're right that one should not use something only because it's a standard, however JDO 2.0 is really powerful and flexible and has both commercial and open-source implementations. It's not finalized yet but most of the new features of this version are already integrated with implementations like JPOX (open-source, in beta status) and Kodo JDO (commercial). > Runtime bytecode enhancement via cglib etc is the name of the game, > having to add another pre-processing stage to your development cycle ( > as you must do with most implementations of jdo is s 2002 ). Using XDoclet, at least with JPOX, this step can be continously intergrated with your build process ;-) I have not used Spring myself but I read somewhere that Spring supports JDO (and Toplink and some other persistence frameworks) as well. For those of you who don't have a good feeling about JDO these two articles from TheServerSide.com are very readable: http://www.theserverside.com/articles/article.tss?l=JDOQueryPart1 http://www.theserverside.com/articles/article.tss?l=JDOQueryPart2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preventing concurrent execution of an Action
Hi > No.. you need to syncrhonize on the lock. > Check the java tutorials on multi-threaded architecture for details. I guess I know enough about multi threading ;) but what I don't know enough is Struts' internals. > A better solution might be to use one of the solutions discussed on the list > on implementing a progress bar, or please wait page when the user clicks the > link. > > http://www.mail-archive.com/cgi-bin/htsearch?config=user_struts_apache_org&restrict=&exclude=&words=progress+b > Lots of thanks for this. It would certainly help me alot. Regards, Behrang S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preventing concurrent execution of an Action (example)
Thanks. This helped me alot.
Regards,
Behrang S.
On Wed, 15 Dec 2004 00:18:46 +0100, Leon Rosenberg <[EMAIL PROTECTED]> wrote:
> Ok, just in case it was more confusing then helping.
> Here is the (imho) safe solution (haven't tested it, but it should work
> fine):
> The isLock method is needed to ensure, that all threads have the same "lock"
> value. Volatile should guarantee it, but it's not supported on all vms. You
> should call the unlock method after you know, that the processing of the
> file is finished.
> Another problem, you could have, is to ensure, that the page where the link
> is placed is still valid. You can ensure it, by giving your call to the
> action a timestamp parameter and check whether it's still the proper
> timestamp for the file.
>
> Here the code (without timestamp):
>
> public class youraction ...{
>
>private volatile boolean lock;
>
>private void lock() throws AlreadyLockedException{
>if (lock)
>throw new AlreadyLockedException();
>
>lock = true;
>}
>
>private void unlock(){
>lock = false;
>}
>
>private synchronized boolean isLocked(){
>return lock;
>}
>
>private synchronized void updateXML() throws AlreadyLockedException{
>//double check needed, in case another thread was already
> //between first isLocked and updateXML call.
>if (isLocked())
>throw new AlreadyLockedException();
>
>lock();
>// generate the xml file.
>unlock();
>
>}
>
>public ActionForward execute(
>ActionMapping mapping,
>ActionForm af,
>HttpServletRequest req,
>HttpServletResponse res)
>throws Exception {
>
>//...
>if (isLocked())
>return mapping.findForward("noupdate");
>try{
>updateXML();
>return mapping.findForward("updatecomplete");
> }catch(AlreadyLockedException e){
>return mapping.findForward("noupdate");
>}
>}
>
> }
>
> > >
> > >
> > > > -Original Message-
> > > > From: Behrang Saeedzadeh [mailto:[EMAIL PROTECTED]
> > > > Sent: Tuesday, December 14, 2004 4:34 PM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Preventing concurrent execution of an Action
> > > >
> > > > Hi
> > > >
> > > > I've an action that creates an XML file on the server. It's executed
> > > > by clicking on a link. I don't want multiple instances of it to be
> > > > executed concurrently.
> > > >
> > > > Does an approach like the following work?
> > > >
> > > > public class UpdateXmlAction ...
> > > > {
> > > >private static final boolean locked;
> > > >
> > > > public void execute(...) {
> > > >
> > > >if (UpdateXmlAction.locked) {
> > > >return;
> > > >}
> > > >
> > > >Synchronized(UpdateXmlAction.class) {
> > > >locked = true;
> > > >updateXml();
> > > >locked = false;
> > > >}
> > > >
> > > >}
> > > > }
> > > >
> > > > Thanks in advance.
> > > >
> > > >
> > > > --
> > > >
> > > > Behrang Saeedzadeh
> > > > http://www.jroller.com/page/behrangsa
> > > >
> > > > -
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Behrang Saeedzadeh
http://www.jroller.com/page/behrangsa
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Preventing concurrent execution of an Action
Hi Thanks for the responses. > You don't need your locked flag, it's provided by java object monitors > automatically. I actually used the lock so if the updateXML is being executed the next request won't even try and wait to aquire the lock for it and simply return. > Last question: if two users click the link simultaneously, what should > happen? In your code, the second user overwrites the changes of the first > user (silently). I guess what I have done ignores the second click as the control returns from the doExecute method before reaching the updateXml method. Regards, Behrang S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Preventing concurrent execution of an Action
Hi
I've an action that creates an XML file on the server. It's executed
by clicking on a link. I don't want multiple instances of it to be
executed concurrently.
Does an approach like the following work?
public class UpdateXmlAction ...
{
private static final boolean locked;
public void execute(...) {
if (UpdateXmlAction.locked) {
return;
}
Synchronized(UpdateXmlAction.class) {
locked = true;
updateXml();
locked = false;
}
}
}
Thanks in advance.
--
Behrang Saeedzadeh
http://www.jroller.com/page/behrangsa
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
