How to avoid 'select for update'
Hi,
we are using the bc4j framework of jdev 3.2.3. We have a View which collects data from several tables in different database schemes, so we naturally have to use the 'union clause'. But if we try to make an update on a row (via 'setAttribute'), we got a DMLException ORA-02014 telling us that we should not use 'select for update' on views whith unions.
Since i cannot avoid using a union clause, is there a way to avoid the 'select for update' in the bc4j framework?
Please help, its urgent!
Thanx,
Dietmar
SELECT FOR UPDATE is used for our implementation or row-level locking.
If you are using pessimistic locking mode, this will occur the first time any attribute is modified.
If you are using optimistic locking mode, it will be deferred until post/commit time.
If you are using "none" locking mode, it will not happen in your application may hang indefinitely if another session has locked the row.
Are you asking how to avoid locking?
Do you mean to be updating this view with a union over multiple databases?
Similar Messages
-
How to SELECT FOR UPDATE with CMP (Oracle)
The most common database (Oracle) by default uses a scheme that does not fit into any of those isolation levels. A SELECT statement selects data at the start of the transactions, whereas a SELECT ... FOR UPDATE does something quite different. It is essential to do SELECT FOR UPDATEs before updating the row as SELECT does no lock. It's a hack that works well in practice.
1. Which isolation level is this?
2. More fundamentally, how an earth is it possible to use this scheme with CMP?! You would have to distinguish load() from loadForUpdate()! Is CMP inconsistent with Oracle?
This is a pretty big whole in the CMP spec!No. thats no goes well.
Transaction serializable in Oracle uses a optimistic
concurrency system. And for update is a
pessimistic concurrency.
With optimistic: the system is faster but it can fail
With pessimistic: if doesnt fail (usually;)
You can solve the proble with many differents systems:
1. Edit the .xml descriptor files ans change the sql sentences.
And my prefer one.
2. Make a new jdbc driver that inherits from the original
oracledriver.
The new driver give u in "getConnection()" a new connection class that inherits from the original connection.
The executestatement and preparestatement adds the
string "for update" if the stattement was starting by select.
Configure your container to use the new driver. -
Should i use SELECT for update NOWAIT ?
Hi:
Do I need to use, in my pl/sql triggers and procedures, the SELECT FOR UPDATE NOWAIT sentence, to avoid locks before using update table sentences ? Is it common to use it on stored procedures and triggers?
Thanks
Joao OliveiraFirst, what, exactly do you mean by "avoid locks"? I was interpreting that to mean "I want to avoid creating locks in my session that might block someone else", not "I want to avoid having my SELECT wait for locks to be released-- I want it to fail immediately". If you meant the latter, then SELECT ... FOR UPDATE NOWAIT would be what you want. If you meant the former, then pessimistic locking is not what you want.
Second, what sort of Oracle Forms architecture do you have? Are you still using old-school client-server applications? Or are you using a three-tiered approach? As Tom discusses in that thread, pessimistic locking is only an option when your client application is able to maintain database state across calls (i.e. client/server systems) not when you have stateless connections (which is the norm in the three-tier model). The old client-server versions of Forms would automatically and transparently do pessimistic locking. Since you didn't mention anything about your architecture, most of us probably assumed the more common stateless client architecture (note how Tom's answers progress over the 5 years in that thread as client/server architecture became less and less common).
Third, while your question is appropriate for either the Database - General forum or the SQL and PL/SQL forum, that generally means that you are free to post it either forum, not that it should be posted in both. The vast majority of the folks that hang out in one forum hang out in the other. It's also rather frustrating to answer a post in one forum only to discover that there is another post in a different forum where someone else had already covered the same points half an hour earlier or to discover that there was additional information in another thread that might have changed your answer.
Fourth, if you are going to do pessimistic locking, that requires that you are able to maintain state across various database calls, that you are locking on the lowest possible level of granularity, and that you are able to time out sessions relatively aggressively to ensure that someone doesn't open a record, thereby locking it, go to lunch (or have their system die) and then block everyone else from working. Assuming that is the case, and that you have some reasonable way to handle the error that gets generated other than simply retrying the operation, adding NOWAIT is certainly an option. Most applications, particularly those getting written today, cannot guarantee all these things, so pessimistic locking is generally not appropriate there.
Looking at your other thread (where there is new information that would be useful in this discussion, one of the reasons that multiple threads are generally a bad idea), it seems that you have an ERP application and you are concerned about the performance of entering orders. Obviously, there shouldn't be any locking issues on the ORDER or ORDER_DETAILS tables, assuming that multiple users aren't going to be inserting the same order at the same time. The contention would almost certainly come when multiple orders are trying to update the STOCK and INVENTORY tables, since multiple orders presumably rely on the same rows in those tables. In that case, I'm not sure what adding a NOWAIT would buy you-- unless you were going to roll back the entire order because someone is updating the STOCK row for #2 pencils and your order has an item of #2 pencils, you'd have to keep retrying the operation until you were able to modify the STOCK row, which would be less efficient than just letting that update block until the row was free.
Now, you could certainly redesign the application to minimize that contention by not trying to update what I assume are aggregate tables like STOCK and INVENTORY directly as part of your OLTP processing or, at least, by minimizing the time that you're locking a row. You could, for example, make STOCK and INVENTORY materialized views rather than tables that refresh ON COMMIT, which should decrease the time that your locks are held. You could also have those tables refreshed asynchronously, which would be even more efficient but may require that you reasses your holdback requirements.
Justin -
Error message: "playlists selected for updating no longer exist"
I tried to update my ipod nano and I guess I had deleted a playlist, but since then, I have not been able to update. Every time I try, I get the following message:
"Cannot be updated because all of the playlists selected for updating no longer exist."
I haven't been able to highlight which playlists are selected to begin with.
I read through the manual and thought that maybe rebooting the whole system might work. So I deleted Itunes from my computer and re-installed.
Then I tried re-setting my ipod. So now I have nothing on my ipod.
I also deleted everything from my library, thinking it might help to start from scratch. Nothing has worked.
How do I "select" and "unselect" playlists so I can get up and running again?Here you go.
http://discussions.apple.com/thread.jspa?messageID=607312򔑐 -
Difference in select for update of - in Oracle Database 10g and 11g
Hi, I found out that Oracle Database 10g and 11g treat the following PL/SQL block differently (I am using scott schema for convenience):
DECLARE
v_ename bonus.ename%TYPE;
BEGIN
SELECT b.ename
INTO v_ename
FROM bonus b
JOIN emp e ON b.ename = e.ename
JOIN dept d ON d.deptno = e.deptno
WHERE b.ename = 'Scott'
FOR UPDATE OF b.ename;
END;
/While in 10g (10.2) this code ends successfully (well NO_DATA_FOUND exception is raised but that is expected), in 11g (11.2) it raises exception "column ambiguously defined". And that is definitely not expected. It seems like it does not take into account table alias because I found out that when I change the column in FOR UPDATE OF e.empno (also does not work) to e.mgr (which is unique) it starts working. So is this some error in 11g? Any thoughts?
Edited by: Libor Nenadál on 29.4.2010 21:46
It seems that my question was answered here - http://stackoverflow.com/questions/2736426/difference-in-select-for-update-of-in-oracle-database-10g-and-11gThe behaviour seems like it really is a bug and can be avoided using non-ANSI syntax. (It makes me wonder why Oracle maintains two query languages while dumb me thinks that this is just a preprocessor matter and query engine could be the same).
-
Lock Cascade With Select for UPDATE
If I had a employee table and a phone table with a parent/child relationship and a primary key constraint on the employee table-will issuing a select for update on the employee also lock the corresponding child rows on the phone table ?
If not how can I bring this about ?You only need two sessions:
First session: Issue the 'select for update'
statements for the row(s) in both tables, don't
rollback or commit
Second session: try to update a row that you tried to
lock in the first session (with NOWAIT).
Thanks. I can try this definitely. A basic question.
You are asking me to do a join on both the tables right ?
Not two individual SQL statements ?
Updating the primary key is known as a Bad Idea (tm).
The key should never be touched because it should be
meaningless. When you have a column that holds 'real'
information it is no candidate for a primary key.
Rgds,
GuidoYes I am aware of that. I was just wondering what is the meaning behind this statement from this link ?
http://www.akadia.com/services/ora_locks_survival_guide.html
And the exact phrase from that link under the section Referential Integrity Locks (RI Locks)
"RI constraints are validated by the database via a simple SELECT from the dependent (parent) table in question-very simple, very straightforward. If a row is deleted or a primary key is modified within the parent table, all associated child tables need to be scanned to make sure no orphaned records will result. "
Thanks again. -
Java.sql.SQLSyntaxErrorException: ORA-02014: cannot select FOR UPDATE from
Experts,
I am getting "java.sql.SQLSyntaxErrorException: ORA-02014: cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc" exception and it leads to one or more setter methods of the VO. I checked the respective attribute in the VO to see if it refers to any LOV with sql having Distinct or group by clause, but it is a normal attribute.
Any idea how do i resolve this error ?
Error Stack::
java.sql.SQLSyntaxErrorException: ORA-02014: cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc.
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:457)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:405)
at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:889)
at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:476)
at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:204)
at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:540)
at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:217)
at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:924)
at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:1261)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1419)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3752)
at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3806)
at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeQuery(OraclePreparedStatementWrapper.java:1667)
at weblogic.jdbc.wrapper.PreparedStatement.executeQuery(PreparedStatement.java:135)
at oracle.jbo.server.OracleSQLBuilderImpl.doEntitySelectForAltKey(OracleSQLBuilderImpl.java:869)
at oracle.jbo.server.BaseSQLBuilderImpl.doEntitySelect(BaseSQLBuilderImpl.java:553)
at oracle.jbo.server.EntityImpl.doSelect(EntityImpl.java:8259)
at oracle.jbo.server.EntityImpl.lock(EntityImpl.java:5964)
at oracle.jbo.server.EntityImpl.setAttributeValueInternal(EntityImpl.java:3756)
at oracle.jbo.server.EntityImpl.setAttributeValue(EntityImpl.java:3635)
at oracle.jbo.server.AttributeDefImpl.set(AttributeDefImpl.java:3203)
at oracle.jbo.server.EntityImpl.setAttributeInternal(EntityImpl.java:1971)
at oracle.jbo.server.AttributeDefImpl.resolveSet(AttributeDefImpl.java:3412)
at oracle.jbo.server.EntityImpl.setAttrInvokeAccessor(EntityImpl.java:1952)
at oracle.jbo.server.EntityImpl.setAttribute(EntityImpl.java:1879)
at oracle.jbo.server.ViewRowStorage.setAttributeValue(ViewRowStorage.java:2327)
at oracle.jbo.server.ViewRowStorage.setAttributeInternal(ViewRowStorage.java:2131)
at oracle.jbo.server.ViewRowImpl.setAttributeInternal(ViewRowImpl.java:1427)
at com.awRostamani.leadWeb.model.uiView.PartyVORowImpl.setNationality(PartyVORowImpl.java:2103)
at com.awRostamani.leadWeb.model.uiView.PartyVORowImpl$AttributesEnum$19.put(PartyVORowImpl.java:207)
at com.awRostamani.leadWeb.model.uiView.PartyVORowImpl.setAttrInvokeAccessor(PartyVORowImpl.java:4204)
at oracle.jbo.server.ViewRowImpl.setAttribute(ViewRowImpl.java:1063)
at oracle.jbo.server.ViewRowImpl.setAttribute(ViewRowImpl.java:1003)
at oracle.jbo.server.ViewRowImpl.setAttributeValues(ViewRowImpl.java:1677)
at oracle.adf.model.binding.DCDataControl.setAttributesInRow(DCDataControl.java:2427)
at oracle.jbo.uicli.binding.JUCtrlValueBinding.setAttributeValuesInRow(JUCtrlValueBinding.java:967)
at oracle.jbo.uicli.binding.JUCtrlListBinding.setTargetAttrsFromLovRow(JUCtrlListBinding.java:2778)
at oracle.jbo.uicli.binding.JUCtrlListBinding.updateTargetFromSelectedValue(JUCtrlListBinding.java:2906)
at oracle.jbo.uicli.binding.JUCtrlListBinding.setAttributeFromValueList(JUCtrlListBinding.java:2851)
at oracle.jbo.uicli.binding.JUCtrlListBinding.setSelectedIndex(JUCtrlListBinding.java:1745)
at oracle.jbo.uicli.binding.JUCtrlListBinding.setInputValueInRow(JUCtrlListBinding.java:3499)
at oracle.jbo.uicli.binding.JUCtrlValueBinding.setInputValue(JUCtrlValueBinding.java:2804)
at oracle.jbo.uicli.binding.JUCtrlValueBinding.setInputValue(JUCtrlValueBinding.java:2767)
at oracle.adfinternal.view.faces.model.binding.FacesCtrlListBinding.setInputValue(FacesCtrlListBinding.java:226)
at oracle.jbo.uicli.binding.JUCtrlValueBinding.put(JUCtrlValueBinding.java:2424)
at oracle.jbo.uicli.binding.JUCtrlListBinding.put(JUCtrlListBinding.java:3395)
at javax.el.MapELResolver.setValue(MapELResolver.java:229)
at com.sun.faces.el.DemuxCompositeELResolver._setValue(DemuxCompositeELResolver.java:252)
at com.sun.faces.el.DemuxCompositeELResolver.setValue(DemuxCompositeELResolver.java:278)
at com.sun.el.parser.AstValue.setValue(Unknown Source)
at com.sun.el.ValueExpressionImpl.setValue(Unknown Source)
at org.apache.myfaces.trinidad.component.UIXEditableValue.updateModel(UIXEditableValue.java:289)
at org.apache.myfaces.trinidad.component.UIXEditableValue.processUpdates(UIXEditableValue.java:252)
at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl$UpdateModelValuesCallback.invokeContextCallback(LifecycleImpl.java:1320)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1410)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnNamingContainerComponent(UIXComponentBase.java:1380)
at oracle.adf.view.rich.component.fragment.UIXRegion.invokeOnComponent(UIXRegion.java:555)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
at oracle.adf.view.rich.component.fragment.ContextSwitchingComponent.invokeOnComponent(ContextSwitchingComponent.java:194)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
at oracle.adf.view.rich.component.fragment.UIXInclude.invokeOnComponent(UIXInclude.java:147)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnChildrenComponents(UIXComponentBase.java:1330)
at org.apache.myfaces.trinidad.component.UIXComponentBase.invokeOnComponent(UIXComponentBase.java:1424)
at oracle.adf.view.rich.component.rich.RichDocument.invokeOnComponent(RichDocument.java:168)
at javax.faces.component.UIComponent.invokeOnComponent(UIComponent.java:720)
at javax.faces.component.UIComponentBase.invokeOnComponent(UIComponentBase.java:678)
at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl._executePhase(LifecycleImpl.java:334)
at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:186)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at oracle.adf.model.servlet.ADFBindingFilter.doFilter(ADFBindingFilter.java:205)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at oracle.adfinternal.view.faces.webapp.rich.RegistrationFilter.doFilter(RegistrationFilter.java:106)
at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl$FilterListChain.doFilter(TrinidadFilterImpl.java:446)
at oracle.adfinternal.view.faces.activedata.AdsFilter.doFilter(AdsFilter.java:60)
at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl$FilterListChain.doFilter(TrinidadFilterImpl.java:446)
at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:271)
at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:177)
at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at com.awRostamani.leadWeb.ui.filter.SecurityCheckFilter.doFilter(SecurityCheckFilter.java:80)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at oracle.adf.library.webapp.LibraryFilter.doFilter(LibraryFilter.java:175)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:111)
at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:313)
at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:413)
at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:94)
at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:161)
at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:71)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at oracle.dms.servlet.DMSServletFilter.doFilter(DMSServletFilter.java:136)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3715)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3681)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2277)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2183)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1454)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
thnksWhen trying to commit from business tester, then also the following error is coming
Jdev 11.1.1.5 - locking mode is optimistic.
OracleSQLBuilderImpl.doEntitySelect failed...
java.sql.SQLSyntaxErrorException: ORA-02014: cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc.
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:457)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:405)
at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:889)
at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:476)
at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:204)
at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:540)
at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:217)
at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:924)
at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:1261)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1419)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3752)
at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3806)
at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeQuery(OraclePreparedStatementWrapper.java:1667)
at oracle.jbo.server.OracleSQLBuilderImpl.doEntitySelectForAltKey(OracleSQLBuilderImpl.java:869)
at oracle.jbo.server.BaseSQLBuilderImpl.doEntitySelect(BaseSQLBuilderImpl.java:553)
at oracle.jbo.server.EntityImpl.doSelect(EntityImpl.java:8259)
at oracle.jbo.server.EntityImpl.lock(EntityImpl.java:5964)
at oracle.jbo.server.EntityImpl.beforePost(EntityImpl.java:6484)
at oracle.jbo.server.EntityImpl.postChanges(EntityImpl.java:6665)
at oracle.jbo.server.DBTransactionImpl.doPostTransactionListeners(DBTransactionImpl.java:3286)
at oracle.jbo.server.DBTransactionImpl.postChanges(DBTransactionImpl.java:3089)
at oracle.jbo.server.DBTransactionImpl.commitInternal(DBTransactionImpl.java:2093)
at oracle.jbo.server.DBTransactionImpl.commit(DBTransactionImpl.java:2374)
at oracle.adf.model.bc4j.DCJboDataControl.commitTransaction(DCJboDataControl.java:1608)
at oracle.adf.model.binding.DCDataControl.callCommitTransaction(DCDataControl.java:1416)
at oracle.jbo.uicli.binding.JUCtrlActionBinding.doIt(JUCtrlActionBinding.java:1437)
at oracle.adf.model.binding.DCDataControl.invokeOperation(DCDataControl.java:2149)
at oracle.jbo.uicli.binding.JUCtrlActionBinding.invoke(JUCtrlActionBinding.java:740)
at oracle.jbo.uicli.jui.JUActionBinding.actionPerformed(JUActionBinding.java:193)
at oracle.jbo.uicli.controls.JUNavigationBar.doAction(JUNavigationBar.java:412)
at oracle.jbo.jbotester.NavigationBar.doAction(NavigationBar.java:111)
at oracle.jbo.uicli.controls.JUNavigationBar$NavButton.actionPerformed(JUNavigationBar.java:118)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:236)
at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:272)
at java.awt.Component.processMouseEvent(Component.java:6289)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
at java.awt.Component.processEvent(Component.java:6054)
at java.awt.Container.processEvent(Container.java:2041)
at java.awt.Component.dispatchEventImpl(Component.java:4652)
at java.awt.Container.dispatchEventImpl(Container.java:2099)
at java.awt.Component.dispatchEvent(Component.java:4482)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4577)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4238)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4168)
at java.awt.Container.dispatchEventImpl(Container.java:2085)
at java.awt.Window.dispatchEventImpl(Window.java:2478)
at java.awt.Component.dispatchEvent(Component.java:4482)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:644)
at java.awt.EventQueue.access$000(EventQueue.java:85)
at java.awt.EventQueue$1.run(EventQueue.java:603)
at java.awt.EventQueue$1.run(EventQueue.java:601)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:98)
at java.awt.EventQueue$2.run(EventQueue.java:617)
at java.awt.EventQueue$2.run(EventQueue.java:615)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:614)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
[348] JUErrorHandlerDlg.reportException(oracle.jbo.DMLException)
[349] DBG: afterActionPerformed :javax_swing_JToolBara1_175
Edited by: in the line of fire on Jul 12, 2011 2:54 PM -
Deadlock detected during SELECT FOR UPDATE - an application error?
I have a general question about how Oracle prevents deadlocks from affecting
applications: do I need to build support into the application for handling
deadlocks when they occur in this particular scenario, or should Oracle handle
this for me? I'd like to know whether this is "normal" behavior for an Oracle
application, or if there is an underlying problem. Consider the following situation:
Two sessions issue individual SELECT FOR UPDATE queries. Each query locates
records in the table using a different index. These indexes point to rows in a
different order from each other, meaning that a deadlock will occur if the two
statement execute simultaneously.
For illustrative purposes, consider these rows in a hypothetical table.
ALPHABET
alpha
bravo
charlie
delta
echo
foxtrot
golf
hotel
Index A results in traversing the table in ascending alphabetical order; index
B, descending. If two SELECT FOR UPDATE statements concurrently execute on this
table--one with an ascending order execution path and one in descending order--
the two processes will deadlock at the point where they meet. If Session A
locks alpha, bravo, charlie, and delta, while Session B locks hotel, golf,
foxtrot, and echo, then neither process can proceed. A needs to lock echo, and
B needs to lock delta, but one cannot continue until the other releases its
locks.
This execution path can be encouraged using hints. Executing queries similar to these on larger tables will generate the "collision" as described above.
-- Session A
select /*+ index_asc (customer) */
from customer
where gender = 'M'
for update;
-- Session B
select /*+ index_desc (customer) */
from customer
where gender = 'M'
for update;
Oracle will recognize that both sessions are in a stand-off, and it will roll
back the work performed by one of the two sessions to break the deadlock.
My question pivots on whether or not, in this situation, the deadlock gets
reported back to the application executing the queries as an ORA-00060. If
these are the ONLY queries executed during these sessions, I would think that
Oracle would rollback the locking performed in one of the SELECT FOR UPDATE
statements. If I understand correctly,
(1) Oracle silently rolls back and replays work performed by UPDATE statements
when a deadlock situation occurs within the scope of the update statement,
and
(2) A SELECT FOR UPDATE statement causes Oracle, at the point in time the cursor
is opened, to lock all rows matching the WHERE clause.
If this is the case, then should I expect Oracle to produce an ORA-00060
deadlock detection error for two SELECT FOR UPDATE statements?
I would think that, for deadlock situations completely within Oracle's control,
this should be perceived to the application invoking the SELECT FOR UPDATE
statements as regular blocking. Since the query execution plans are the sole
reason for this deadlock situation, I think that Oracle would handle the
situation gracefully (like it does for UPDATE, as referenced in (1)).
Notice, from the trace file below, that the waits appear to be from row locking,
and not from an artificial deadlock (e.g. ITL contention).
Oracle8i Enterprise Edition Release 8.1.7.4.0 - 64bit Production
With the Partitioning option
DEADLOCK DETECTED
Current SQL statement for this session:
SELECT XXX FROM YYY WHERE ZZZ LIKE 'AAA%' FOR UPDATE
----- PL/SQL Call Stack -----
object line object
handle number name
58a1f8f18 4 anonymous block
58a1f8f18 11 anonymous block
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
TX-002f004b-000412cf 37 26 X 26 44 X
TX-002e0044-000638b7 26 44 X 37 26 X
session 26: DID 0001-0025-00000002 session 44: DID 0001-001A-00000002
session 44: DID 0001-001A-00000002 session 26: DID 0001-0025-00000002
Rows waited on:
Session 44: obj - rowid = 0000CE31 - AAANCFAApAAAAGBAAX
Session 26: obj - rowid = 0000CE33 - AAANCHAArAAAAOmAAM
Thanks for your insight,
- Curtis
(1) "Oracle will silently roll back your update and restart it"
http://tkyte.blogspot.com/2005/08/something-different-part-i-of-iii.html
(2) "All rows are locked when you open the cursor, not as they are fetched."
http://download-east.oracle.com/docs/cd/A87860_01/doc/appdev.817/a77069/05_ora.htm#2170
Message was edited by:
Curtis LightThanks for your response. In my example, I used the indexes to force a pair of query execution plans to "collide" somewhere in the table in question by having one query traverse the table via index in an ascending order, and another in descending. This is an artificial scenario for reproducible illustrative purposes, but similar collisions could legitimately occur in real world scenarios (e.g. a full table scan and an index range scan with lookup by ROWID).
So, with that said, I think it would be unreasonable for Oracle to report the collision as a ORA-00060 every time it occurs because:
(1) The UPDATE statement handles this situation automatically, and
(2) An ORA-00060 results in a 100+KB trace file being written out, only rational for truly erroneous situations.
I agree that, when the application misbehaves and locks rows out of order in separate SQL statements, then Oracle should raise an ORA-00060, as the deadlock is outside of its control. But in this case, the problem occurs with just two individual SQL statements, each within its own transaction. -
Pros and cons of select for update clause
hi,
Can anybody explain what are the
pros and cons of select for update clause
11.2.0.1As commented, there are no pros versus cons in this case.
What is important is to understand conceptually what this do and why it would be use.
Conceptually, a select for update reads and locks row(s). It is known as pessimistic locking.
Why would you want to do that? Well, you have a fat client (Delphi for example) and multiple users. When userA updates an invoice, you want that invoice row(s) locked and prevent others from making updates at the same time. Without locking, multiple users updating the same invoice will result in existing updated data being overwritten by old data that also has been updated. A situation called lost updates.
For web based clients that are stateless, pessimistic locking does not work - as the clients do not have state and pessimistic locking requires state. Which means an alternative method to select for update needs to be used to prevent lost updates. This method is called optimistic locking.
So it is not about pros versus cons. It is about understanding how the feature/technique/approach works and when to use it.. and when it is not suited to use it. All problems are not nails. All solutions are not the large hammer for driving in nails. -
Inconsistent Locking with Select for Update
Hi,
I seem to be having some issues in using SELECT FOR UPDATE and was hoping to get some insight from the Oralce Guru's out there.
I have a J2EE application, running in WebLogic 8.1.4 using Oralce 9.2.0.1.0.
The application contains code that requires locking to be done on a specific table with multiple transactions (tx) requesting the same lock. Eg:
Tx 1: Select * from Zone where Zoneid = 'Zone1' for update (Obtains lock)
Tx 2: Select * from Zone where Zoneid = 'Zone1' for update (waits)
Tx 100: Select * from Zone where Zoneid = 'Zone1' for update
Tx1 commits.
It appears that the following transactions, i.e. Tx2 - Tx100 do not seem to execute in the order the lock was requested. That is Tx 100 always appears to be the second last transaction to execute, after which some arbitrary transaction between Tx2 - Tx99 will execute after Tx100 has committed.
This seems to tell me that the lock is not being handed in a FIFO manner and is causing us great pain as our data is not longer consistent.
Does anyone know how i might be able to trace which transaction is being awarded the lock? Also if anyone has any suggestion on how to troubleshoot/solve this issue, greatly appreciated.
TIA
PremOracle does not have a lock queue/manager at all. The locked status of a record is essentially an attribute of the record itself. It is stored on the datablock header. When a transaction requests a lock and can't get it, and is willing to wait (SELECT FOR UPDATE without NOWAIT), it first spins while waiting for the lock (four times as I recall), then sleeps waiting for the lock. The the more times it sleeps before getting the lock, the longer it will sleep before trying again.
What is likely happening here is that transaction 100 is still spinning when transaction 1 commits, so checks back more frequently and gets the lock first. The rest get the lock whenever they wake up and noone else has taken the lock.
If you need the transaction to occur in order, then I do not think you can use Oracle's native locking mechanism. Depending on what exactly you are trying to do, you may want to look at Advanced Queueing, or possibly the built-in package DBMS_LOCK.
HTH
John -
List current DML in DB including SELECT for Update
In order to list all currently opened DML we can select v$open_cursor and link it to to v$SQL in order to retrieve the v$SQL.COMMAND_TYPE.
All DML operation have the following number in v$sql.command_type :
2 : 'INSERT'
6 : 'UPDATE',
7 : 'DELETE',
189 : 'MERGE'
But 'SELECT for update it is still 3 like any non regular SELECT.
I did not found information in v$lock nor in v$transaction that would allow me
to link an open cursor of type 3 (SELECT but in fact for update) to the opened transaction in v$transaction.
Does anybody knows how to assert than a SELECT is in fact a DML short of grepping the 'FOR update' in the SQL text.
Such an Horrible trick would force me to search all opened cursor text for each session with an entry in v$transaction.Thanks for replying.
I could have had the usage of less aggressivity and more competences. You advice is simply stupid :
-- seesion 1 :
select * from toto where id = 20 for update ;
select sid from v$mystat where rownum = 1 ; -- > sid=1614
-- session control : check v$transaction
col version new_value version noprint
col field new_value field noprint
col used_urec format 999999 head 'Undo|Records'
col undo_size head 'Undo|size (k)' justify c
set lines 150
select substr(version,1,instr(version,'.',1)-1) version from v$instance;
select decode(&version,9,'','XID,') field from dual;
Select r.segment_name,To_Char(To_Date(vt.Start_Time,'MM-DD-RR HH24:MI:SS'),'MM-DD HH24:MI:SS') strt
, decode(vs.status,'ACTIVE',vs.last_Call_et,0) since , vs.sid, vs.status se_status,
&field vt.status tr_status, log_io, phy_io,cr_get,cr_change, vt.used_urec, vt.used_ublk * p.value/1024 undo_size
From dba_rollback_segs dr,
v$rollstat rs,
v$transaction vt,
v$session vs,
v$process vp,
dba_rollback_segs r,
v$parameter p
Where vs.Paddr = vp.Addr (+) AND p.name = 'db_block_size'
and vt.xidusn (+) = r.segment_id
And vs.UserName Is Not Null
And vs.Taddr Is Not Null
And vs.Taddr = vt.Addr
And vt.xidusn = dr.segment_id
And vt.xidusn = rs.usn
Order By VS.OsUser, To_Date(vt.Start_Time,'MM-DD-RR HH24:MI:SS') ;
Running Session Transact Undo Undo
SEGMENT_NAME Start time time (s) SID Status XID Status LOG_IO PHY_IO CR_GET CR_CHANGE Records size (k)
_SYSSMU21$ 04-13 11:02:24 0 1614 INACTIVE 0015002A0003A800 ACTIVE 3 0 104 0 1 8
-- so we have a transaction in 1614. Let's retrieve its SQL :
-- session control : what do we have in v$session :
1 select sql_hash_value, b.sql_text sql_text, prev_hash_value , bb.sql_text prev_sql_text
2 from
3 v$session a, v$sql b, v$sql bb
4 where sid = 1614
5 and a.sql_hash_value = b.hash_value (+)
6* and a.prev_hash_value = bb.hash_value (+)
SQL> /
SQL_HASH_VALUE SQL_TEXT PREV_HASH_VALUE PREV_SQL_TEXT
0 897388722 select sid from v$mystat where rownum = 1
-- gone !
-- Conclusion : joining v$session to v$transaction is useless if you want to retrieve the SQL in system currently opened.
-- moreover, if start a transaction with many queries, you are still limited to 2 slot in v$session. -
How to avoid selection-screen?
Hi,
i have this short report:
TABLES: MARA.
SELECT-OPTIONS: S_MATNR FOR MARA-MATNR.
AT SELECTION-SCREEN.
IF SY-BATCH = 'X'.
* how to avoid selection screen
ENDIF.
START-OF-SELECTION.
SELECT * FROM MARA WHERE MATNR IN S_MATNR.
WRITE: / MARA-MATNR.
ENDSELECT.
END-OF-SELECTION.
in batch i don't want the selection-screen. Is it possible? How can i do this?
Thanks.
regards, DieterDieter Gröhn wrote:
> Hi,
>
> i have this short report:
>
>
> TABLES: MARA.
> SELECT-OPTIONS: S_MATNR FOR MARA-MATNR.
> *
> AT SELECTION-SCREEN.
> IF SY-BATCH = 'X'.
> * how to avoid selection screen
> ENDIF.
> *
> ************************************************************************
> START-OF-SELECTION.
> *
> SELECT * FROM MARA WHERE MATNR IN S_MATNR.
> WRITE: / MARA-MATNR.
> ENDSELECT.
> *
> END-OF-SELECTION.
>
>
> in batch i don't want the selection-screen. Is it possible? How can i do this?
>
> Thanks.
>
> regards, Dieter
Please check the value of the variable sy-binpt, I believe the value of the variable sy-binpt will be set to 'X' if the program is called from a bath input, hope this helps. -
Audit "SELECT FOR UPDATE" statement
Hi all
My database is 10.2.0.3 and I enabled audit_trail to DB value already.
My purpose I want to audit "SELECT FOR UPDATE" statement on the table and I tried to enable audit "SELECT" on the table that have many records in dba_audit_trail because "SELECT" statement that include in this audit and then I tried to enable audit "LOCK TABLE" on the table that doesn't have any records n dba_audit_trail.
So my question is How to enable audit for collecting only "SELECT FOR UPDATE" statement? or anyone have any idea for this.
Regards,
Hikotaohiko wrote:
Hi all
My database is 10.2.0.3 and I enabled audit_trail to DB value already.
My purpose I want to audit "SELECT FOR UPDATE" statement on the table and I tried to enable audit "SELECT" on the table that have many records in dba_audit_trail because "SELECT" statement that include in this audit and then I tried to enable audit "LOCK TABLE" on the table that doesn't have any records n dba_audit_trail.
So my question is How to enable audit for collecting only "SELECT FOR UPDATE" statement? or anyone have any idea for this.
A consideration on top of the comments made by Justin:
You have an unfortunate version of the database for auditing: when you enable audit on 10.2.0.3 (or.2 or .1) the redo pattern changes - normally you will see a redo change vector for each row updated, but in these versions you will see two records, a "lock row" followed up "update row piece"; which means your volume of redo may increase significantly.
I wrote a note about it some time ago: http://jonathanlewis.wordpress.com/2011/05/27/audit-ouch/ and one of the comments includes the bug number ( 5166745 ), reporting fixed in 10.2.0.4 and 11.1.0.6
Regards
Jonathan Lewis
This is bug -
DBMS_LOCK vs Select for update locking
Hi,
In one of our database packages, we are using the dbms_lock (that package is used to generate unique numbers) instead of select for update locking.
I want to ask what is more suitable here. Our application is oracle forms and oracle db on oracle app server.
Are there any limitations to select for update locking?
What are the conditions favourable to use DBMS_LOCK?
Regards,DBMS_LOCK is extremely efficient. Try it. Put a call to obtain/free a lock in a loop and see how long it takes to loop a few thousand times (don't SLEEP in the loop, just obtain and free the lock). If you are having performance issues with DBMS_LOCK or your select it is probably because whatever it is that gets the lock (whichever way you get it) is taking a certain amount of time to finish.
I too, am curious as to what "issues" you had. In either case, a lock for consistent read will be different than a lock for update (as it should be) in terms of how it impacts other users. -
Trigger with SELECT-FOR-UPDATE
There is a trigger on a table, which updates a particular column with SYSDATE BEFORE an INSERT OR UPDATE in the table.
CREATE OR REPLACE TRIGGER my_schema.trg_Order
BEFORE INSERT OR UPDATE
ON my_schema.ORDER
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
:NEW.LAST_UPDATE_DATE := SYSDATE;
END;
If I update the record using PL/SQL with SELECT-FOR-UPDATE & then UPDATE, the column LAST_UPDATE_DATE is not updated with the SYSDATE.
But if it is done by using the UPDATE Statement, then the column LAST_UPDATE_DATE is correctly updated with the SYSDATE.
Why? How can I ensure that for SELECT-FOR-UPDATE & then UPDATE will also update the LAST_UPDATE_DATE with SYSDATE.The Table Order has a BLOB column.
Maybe you are looking for
-
Difficult to open files saved in the MAC PC when working on the network.
Working on a network that has Mac and PC sharing and using the same file, but yesterday the illustrator went to the windows to open files saved in the MAC network. If I save the file on the hard drive it opens, but if you are not on the network. But
-
How to read and write from the serial port using java
can anyone tel me how to capture data from a serial port and display on the screen and also store it in a database.
-
How to process a file with out any CSV, Delimitaor, fixed length or Copybok
Hi Team, i need to process below file in OSB and need to send mails to the concerns ids... this file will have either 1 mail or multiple mails. sample.txt file with 1 mail content ====================================== START [email protected] [email
-
Hi I'm trying to create an Aperture-like shape in Illustrator CC by combining a circle/elipse with a sheared square, but not getting very far. I've tried the Help Section ...even tried the Illustrator CC Classroom Book for answers. I would appreciate
-
Can I purchase online prints from iPhoto for ipad
Based on the Apple website for iPhoto, it appeared that I could order prints or other photo products. I purchased the iPhoto app for this purpose and unless I'm missing something I don't see this as an option.